1 |
Dave Nebinger <dnebinger <at> joat.com> writes: |
2 |
|
3 |
|
4 |
> > OK on the local rsync server I added this to automate the daily |
5 |
|
6 |
> > 30 1 * * * root emerge sync |
7 |
|
8 |
> Unless you want to receive the daily email full of all kinds of funky |
9 |
> characters, I'd redirect the output from emerge to a file. On my boxen I |
10 |
> call 'dailysync.sh' from cron. The script has this: |
11 |
|
12 |
OK but can't I do that with a simple mode to the /etc/crontab ?: |
13 |
30 1 * * * root emerge sync 2>&1 |
14 |
? |
15 |
|
16 |
> cornholio ~ # cat bin/dailysync.sh |
17 |
> #!/bin/sh |
18 |
> # |
19 |
> # sync.sh: Script to handle the portage syncing. |
20 |
|
21 |
> emerge --sync 1>>/var/log/autosync.log 2>&1 |
22 |
|
23 |
> # Update eix and edb... |
24 |
> if [ -e /usr/portage/profiles/default-linux/x86/2005.0/make.defaults ] |
25 |
> then |
26 |
> echo Not recreating make.defaults, it exists... >>/var/log/autosync.log |
27 |
> else |
28 |
> echo Recreating make.defaults... >>/var/log/autosync.log |
29 |
> ln -sf ../make.defaults |
30 |
> /usr/portage/profiles/default-linux/x86/2005.0/make.defaults |
31 |
> 1>>/var/log/autosync.log 2>&1 |
32 |
> fi |
33 |
|
34 |
> eix -u 1>>/var/log/autosync.log 2>&1 |
35 |
> eupdatedb 1>>/var/log/autosync.log 2>&1 |
36 |
|
37 |
OK, I can try this script. I guess eix is an ebuild index |
38 |
& searching tool, that I need to read up on... |
39 |
|
40 |
This script is for the internal rsync/replicator server? |
41 |
|
42 |
|
43 |
> The if/then logic is needed because eix expects a <version>/make.defaults |
44 |
> file, but the make.defaults has been pushed up one directory level. The |
45 |
> emerge --sync wipes the file out so I have to recreate it before updating |
46 |
> eix. And the output from the script goes to a log file rather than |
47 |
> stdout/stderr (so when run via cron no email is generated). |
48 |
|
49 |
> > OK, now I use document (C) to create the proxy entry on each client: |
50 |
> > Editing File: /etc/env.d/99local to look like this |
51 |
> > http_proxy="192.168.2.9:8080" |
52 |
> > instead of this |
53 |
> > http_proxy="proxy.server.com:8080" |
54 |
|
55 |
> > I check it on the client by issuing "echo $http_proxy" |
56 |
> > which give the correct results: |
57 |
> > 192.168.2.9:8080 |
58 |
|
59 |
> > So far so good??? |
60 |
|
61 |
> Hmm, the documentation might have changed since I did my setup. My internal |
62 |
> boxes have 'http_proxy=http://192.168.0.1:8084' directly in the make.conf |
63 |
> file; I didn't make any changes to /etc/conf.d/local.start for the http |
64 |
> proxy. |
65 |
|
66 |
OK, the port has changed. What's the deal about that? |
67 |
|
68 |
> > and last run this daily on the server to keep it current? |
69 |
> > emerge -uDva world && repcacheman |
70 |
|
71 |
> Well if you have the time and inclination you can do it daily. Once you get |
72 |
> into maintaining the system you'll realize that this kind of attention to |
73 |
> the box is frequently overkill - a working box is a working box and there is |
74 |
> no need to fix what isn't broken. |
75 |
|
76 |
> Rather than do this on a daily basis I generate a daily email of packages to |
77 |
> be updated; if I see one I feel is critical I'll deal with the update |
78 |
> otherwise I'll let the system go for awhile. The script I use for this is: |
79 |
|
80 |
OK, monthly on a manual basis. I'll try your script/email approach. |
81 |
|
82 |
> cornholio ~ # cat bin/updatereport.sh |
83 |
> #!/bin/sh |
84 |
|
85 |
> # updatereport.sh: Script to send an update report to root. |
86 |
|
87 |
> # Remove the old report file. |
88 |
|
89 |
> if [ -e /var/log/update.report ] ; then |
90 |
> /bin/rm -f /var/log/update.report |
91 |
> fi |
92 |
> if [ -e /var/log/update.rpt.txt ] ; then |
93 |
> /bin/rm -f /var/log/update.rpt.txt |
94 |
> fi |
95 |
|
96 |
> # Run the command to generate the output file. |
97 |
|
98 |
> emerge --pretend --update --deep world 1>/var/log/update.report |
99 |
|
100 |
> # Put a standard header at the top of the text file. |
101 |
|
102 |
> echo "Current gentoo update report." > /var/log/update.rpt.txt |
103 |
> echo "" >> /var/log/update.rpt.txt |
104 |
> date >> /var/log/update.rpt.txt |
105 |
> echo "" >> /var/log/update.rpt.txt |
106 |
|
107 |
> # Extract a clean text file |
108 |
|
109 |
> strings /var/log/update.report >> /var/log/update.rpt.txt |
110 |
|
111 |
> # Mail the clean text file. |
112 |
|
113 |
> mail -s "Cornholio Portage Update Report" root < /var/log/update.rpt.txt |
114 |
|
115 |
|
116 |
OK thanks for the script. I'll have to study it, test it and let you know |
117 |
how it goes... |
118 |
|
119 |
|
120 |
> > Anything I missed? |
121 |
|
122 |
> Well sure. The part I should have mentioned is that if your systems are all |
123 |
> similar in that they have the same hardware and same use flags, package |
124 |
> installs, etc., then you might want to have one system build binary packages |
125 |
> for distribution to the internal systems. That way you only suffer the |
126 |
> build once. |
127 |
|
128 |
In the future I'll be distributing binaries to lots of old pI and pII systems, |
129 |
so that kind of automation will have to wait. |
130 |
|
131 |
|
132 |
> Personnaly I've got different architectures (PIII, P4, and AMD) mixed in |
133 |
> and, as each system has a different purpose they typically don't have |
134 |
> similar use flags or package installations, so a binary package distribution |
135 |
> doesn't work for me. |
136 |
|
137 |
ditto. |
138 |
|
139 |
> > Surely parts of all (4) documents belong in one master howto? |
140 |
|
141 |
> I'm sure it could but there's probably folks on the other side of the fence |
142 |
> that only want a local rsync mirror or a local portage download cache and |
143 |
> not both. |
144 |
|
145 |
Well the simple cases are easy. What I need, including your scripts is |
146 |
to be in a single document. I'll write something, and you can look it |
147 |
over. That helps me fully understand what everything does, and provides |
148 |
a nice little document. I tend to 'dumb down' documents, so they are |
149 |
easy to understand.... I also include more background material |
150 |
so novices and seasoned persons can use them. |
151 |
|
152 |
> > Is there a script to update workstation systems, automatically, |
153 |
> > say 10 minutes after booting? How best to do this? |
154 |
|
155 |
> Sure. Generate a script that sleeps for 10 minutes then kicks off the |
156 |
> emerge process. Call the script from /etc/conf.d/local.start (be sure to |
157 |
> include the & to spawn it in the background) and you're golden. |
158 |
|
159 |
> However, you need to consider if this is something that you really want to |
160 |
> do. Automated updates are frowned upon by folks on the list. |
161 |
|
162 |
|
163 |
Agreed. But I intend to set up a test-quarrantine system that is fully |
164 |
automated, and if all goes well for (1) 24-hour period, then push the |
165 |
updates to a bunch of PI and PII systems for a bunch of kids (hoodlums.... |
166 |
some of which are mine.) |
167 |
|
168 |
Thanks for the help and scripts... |
169 |
James |
170 |
|
171 |
|
172 |
|
173 |
-- |
174 |
gentoo-user@g.o mailing list |