script to update patches during boot
Roel Kluin
useful to others, are there any reasons thinkable why this shouldn't be
done? any suggestions? TIA.
Save this script as /etc/rc.d/rc.updateslack
#!/bin/bash
# copyright GPL v2.0 by Roel Kluin 2007
#specify the user authorized for downloading and storage of packages
PKGUSR="<your username here>"
#specify your favorite mirror
RSYNCHOST="<your favorite rsync host>"
#is equal to VERSION="12.0"
VERSION="`cat /etc/slackware-version | cut -b 11-14`"
# where you want to install these packages
DESTDIR="/home/$PKGUSR/dnld/slackware/slackware-$VERSION"
RSYNC="$RSYNCHOST::slackware/slackware-$VERSION/patches"
BEFORE=`date +%Y%m%d%M%S`
echo checking for updated slackware-$VERSION patches...
su - $PKGUSR -c "mkdir -p $DESTDIR"
su - $PKGUSR -c "rsync -q --exclude=patches/source -v --progress \
-az --delete --log-file=$DESTDIR/rsync.log $RSYNC $DESTDIR/"
cd $DESTDIR/patches
cat CHECKSUMS.md5 | grep -e ".tgz$" | while read sum file; do
# only updated files should are checked and installed
if [ `date -r $file +%Y%m%d%M%S` -ge $BEFORE ]; then
if [ "`openssl md5 $file | cut -d" " -f 2-`" = "$sum" ]; then
if [ "`gpg --verify $file.asc 2>&1 | grep Slackware | cut -d" " -
f2`" = "Good" ]; then
upgradepkg --install-new $file
else
echo ERROR: SIGN of $file is not OK!
fi
else
echo ERROR: MD5 sum of $file is not OK!
fi
fi
done
#end script
dont forget to chmod a+x /etc/rc.d/rc.updateslack
add these lines to your /etc/rc.d/rc.local file:
if [ -x /etc/rc.d/rc.updateslack ]; then
/etc/rc.d/rc.updateslack
fi
Martin Lefebvre
> I wrote this script to update slackware patches during boot. Maybe it's
> useful to others, are there any reasons thinkable why this shouldn't be
> done? any suggestions? TIA.
>
I can just imagine... working, having to reboot for some reason, then
"crap!!! my system is updating!" sounds kinda windows-updatish to me :P
as to why it might be a bad idea, other than forcing you to update the
system when you might not want to, it can slow down boot by a lot if your
network is not up, or if the specific rsync host is down when you boot...
Martin Lefebvre
sorry for answering to my own post...
you also do not seem to follow the order specified in the UPGRADE.TXT file,
which can create problems, as it has been seen with other upgrade tools
which shall remain nameless for obvious reasons...
Steve Youngs
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
* Roel Kluin <rjckluin@hot_n0zpam_mail.com> writes:
> I wrote this script to update slackware patches during boot. Maybe it's
> useful to others, are there any reasons thinkable why this shouldn't be
> done? any suggestions? TIA.
There were a few things I would have done differently, plus a big fat
bug. I'll make some comments through your script and at the end include
my version of it.
> #!/bin/bash
> # copyright GPL v2.0 by Roel Kluin 2007
> #specify the user authorized for downloading and storage of packages
> PKGUSR="<your username here>"
No need to quote the value here, user names can't have naughty
characters in them anyway.
> #specify your favorite mirror
> RSYNCHOST="<your favorite rsync host>"
No quoting needed here, FQDN's can't have naughty characters either.
> #is equal to VERSION="12.0"
> VERSION="`cat /etc/slackware-version | cut -b 11-14`"
This is a UUOC (Useless Use Of Cat), and still quoting not needed. :-)
> # where you want to install these packages
> DESTDIR="/home/$PKGUSR/dnld/slackware/slackware-$VERSION"
> RSYNC="$RSYNCHOST::slackware/slackware-$VERSION/patches"
> BEFORE=`date +%Y%m%d%M%S`
I really don't understand what you are trying to do with this. It
looks very wrong to me. You set a timestamp of when the script starts,
and then only update files that are _newer_ than this stamp. I think a
better way would be to touch a "LAST_UPDATED" file at the _end_ of a
successful run of this script, and in the guts of it you update any
files that are newer than the LAST_UPDATED file. I'll rewrite the
following code with that method.
> echo checking for updated slackware-$VERSION patches...
> su - $PKGUSR -c "mkdir -p $DESTDIR"
> su - $PKGUSR -c "rsync -q --exclude=patches/source -v --progress \
> -az --delete --log-file=$DESTDIR/rsync.log $RSYNC $DESTDIR/"
This can be done from a single `su', and there is no need to use the `-'
arg to su here.
> cd $DESTDIR/patches
> cat CHECKSUMS.md5 | grep -e ".tgz$" | while read sum file; do
> # only updated files should are checked and installed
> if [ `date -r $file +%Y%m%d%M%S` -ge $BEFORE ]; then
> if [ "`openssl md5 $file | cut -d" " -f 2-`" = "$sum" ]; then
> if [ "`gpg --verify $file.asc 2>&1 | grep Slackware | cut -d" " -
> f2`" = "Good" ]; then
> upgradepkg --install-new $file
> else
> echo ERROR: SIGN of $file is not OK!
> fi
> else
> echo ERROR: MD5 sum of $file is not OK!
> fi
> fi
> done
> #end script
This just looks really wrong and a bit convoluted to me. The big fat
bug I spoke of is this line...
if [ `date -r $file +%Y%m%d%M%S` -ge $BEFORE ]; then
Which says: if the modification time of $file is greater than or equal
to the time stored in $BEFORE. And in this case, greater than or equal
to means: _newer_, or _more recent_. So you'd only update files that
were modified _after_ you start the script. Don't forget that rsync
preserves the mtimes of files.
> add these lines to your /etc/rc.d/rc.local file:
> if [ -x /etc/rc.d/rc.updateslack ]; then
> /etc/rc.d/rc.updateslack
> fi
Unless you are booting on a fairly regular basis, I wouldn't bother
adding it to rc.local. Instead, I'd run it from cron.
Here is my version of your script. Please be aware that I didn't test
it, so use it at your own risk...
#!/bin/bash
# copyright GPL v2.0 by Roel Kluin 2007
#specify the user authorized for downloading and storage of packages
# edit me
PKGUSR=username
#specify your favorite mirror
# edit me
RSYNCHOST=my.favourite.mirror
#is equal to VERSION="12.0"
VERSION=$(cut -b 11-14 /etc/slackware-version)
# where you want to install these packages
DESTDIR=/home/${PKGUSR}/dnld/slackware/slackware-${VERSION}
RSYNC=${RSYNCHOST}::slackware/slackware-${VERSION}/patches
echo checking for updated slackware-$VERSION patches...
su $PKGUSR -c "\
{ [ -d ${DESTDIR} ] || mkdir -p ${DESTDIR} } &&
rsync -q --exclude=patches/source -v --progress -as --delete \
--log-file=${DESTDIR}/rsync.log ${RSYNC} ${DESTDIR}/"
# The lack of a `\' on the line ending with `&&' is not a typo, it's
# not needed.
cd $DESTDIR/patches
lastupd=/path/to/LAST_UPDATED
inst=0
while read sum file; do
if [ ${file} -nt ${lastupd} ]; then
if [ $(openssl md5 ${file}|cut -d' ' -f2) = ${sum} ]; then
gpg --verify ${file}.asc ${file} 2>/dev/null &&
upgradepkg --install-new ${file} ; (( ++inst )) ||
echo BAD sig for: ${file} >&2
else
echo ERROR: BAD md5 sum for: ${file} >&2
fi
fi
done < grep -e ".tgz$" CHECKSUMS.md5
[ $inst -gt 0 ] && touch ${lastupd}
#end script
HTH
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| Genius - Is the ability to reduce |
| the complicated to the simple |
|----------------------------------<st...@youngs.au.com>---|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: The SXEmacs Project <http://www.sxemacs.org>
Comment: Eicq - The SXEmacs ICQ Client <http://www.eicq.org/>
iEYEARECAAYFAkbacRAACgkQHSfbS6lLMAN4xgCgvYDHTXr8G2VI+C9Xuklgv4Th
K5cAnjn38sbqVpPjpI1wMH5FZgNguCJd
=W0Re
-----END PGP SIGNATURE-----
Roel Kluin
> Martin Lefebvre <dade...@gmale.com> wrote:
> I can just imagine... working, having to reboot for some reason, then
> "crap!!! my system is updating!" sounds kinda windows-updatish to me :P
lol. It won't end with a blue screen of death, though.
> It can slow down boot by a lot if your network is not up, or if the
> specific rsync host is down when you boot...
Ok, you got a point there.
> you also do not seem to follow the order specified in the UPGRADE.TXT
For only patches there is no such UPGRADE.TXT, is there?
Henrik Carlqvist
> I wrote this script to update slackware patches during boot. Maybe it's
> useful to others, are there any reasons thinkable why this shouldn't be
> done? any suggestions? TIA.
Depending on how you use your computer you might not wan't to do it at
boot. Instead you might want to consider to call the script from a cron
job. I see two disadvantages of updating the machine at boot. First, every
time you reboot you will have to wait for the script, second if you never
reboot the machines will not get updated. On the other hand, if the
updates are done from a cron job which is run at a time when the machine
is shut down it will also end up being non-updated.
Another thing to consider is if you really wan't to install all patches.
During the years there have been a number of patches which I have choosen
not to install. Sometimes there is a warning in ChangeLog.txt that
installing a patched application X is going to break application Y. At
those occasion you might want to manually determine if the security hole
in application X is more important to fix than to keep a working
application Y. At some other few times I have found that patches has
broken some functionality.
My method for updating machines has been:
1) Calling a script which downloads packages
2) Manually use gpg to verify downloaded packages
3) Consider which packages to install
4) Install those patches on a test machine.
5) Verify that the patched applications still work as expected.
6) Copy patches to a central patch repository
7) Make symbolic links in a central update directory.
8) Remove any links to older patches for the same packages.
Then I have a cron job which every night runs the following Makefile in
the update directory on all machines:
-8<---------------------------------------------------
PACKAGES = $(wildcard *.tgz)
LOG_FILES = $(PACKAGES:%.tgz=/var/log/packages/%)
all: $(LOG_FILES)
/var/log/packages/%: %.tgz
upgradepkg --install-new $<
-8<---------------------------------------------------
The cron job consists of a file, /etc/cron.daily/slack_update , which
looks like this:
-8<---------------------------------------------------
#!/bin/sh
( cd /auto/slack120/updates ; make ) > /var/log/slack_update
-8<---------------------------------------------------
Scripts in /etc/cron.daily are run by cron every night (or rather early in
the morning).
My method of keeping machines up to date involves quite a bit of more
manual work than your nice script. However, this is the price I have to
pay to avoid risking that I get a patch installed that would break
something.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Roel Kluin
Thanks for sharing your insight.
> > VERSION="`cat /etc/slackware-version | cut -b 11-14`"
>
> This is a UUOC (Useless Use Of Cat), and still quoting not needed. :-)
Just like in real life: try to cut the cat and you'll get nailed.
> > echo checking for updated slackware-$VERSION patches... su - $PKGUSR
> > -c "mkdir -p $DESTDIR"
> > su - $PKGUSR -c "rsync -q --exclude=patches/source -v --progress \
> > -az --delete --log-file=$DESTDIR/rsync.log $RSYNC $DESTDIR/"
>
> This can be done from a single `su', and there is no need to use the `-'
> arg to su here.
That a single su could be used I knew, the second I did not, thanks.
> if [ `date -r $file +%Y%m%d%M%S` -ge $BEFORE ]; then
>
> Which says: if the modification time of $file is greater than or equal
> to the time stored in $BEFORE. And in this case, greater than or equal
> to means: _newer_, or _more recent_. So you'd only update files that
> were modified _after_ you start the script. Don't forget that rsync
> preserves the mtimes of files.
I didn't know that rsync preserved mtimes. Now that you say it, that's
probably WHY they call it rsync.
> Unless you are booting on a fairly regular basis, I wouldn't bother
> adding it to rc.local. Instead, I'd run it from cron.
Ok, I'l have to read some manpages bout cron.
> Here is my version of your script. Please be aware that I didn't test
> it, so use it at your own risk...
I tested it and I eliminated some bugs :P
> #!/bin/bash
> # copyright GPL v2.0 by Roel Kluin 2007
>
> #specify the user authorized for downloading and storage of packages #
> edit me
> PKGUSR=username
>
> #specify your favorite mirror
> # edit me
> RSYNCHOST=my.favourite.mirror
>
> #is equal to VERSION="12.0"
> VERSION=$(cut -b 11-14 /etc/slackware-version)
>
> # where you want to install these packages
> DESTDIR=/home/${PKGUSR}/dnld/slackware/slackware-${VERSION}
>
> RSYNC=${RSYNCHOST}::slackware/slackware-${VERSION}/patches
>
> echo checking for updated slackware-$VERSION patches...
>
> su $PKGUSR -c "\
> { [ -d ${DESTDIR} ] || mkdir -p ${DESTDIR} } && rsync -q
you have to put a smicolon after mkdir -p ${DESTDIR}
> --exclude=patches/source -v --progress -as --delete \
> --log-file=${DESTDIR}/rsync.log ${RSYNC} ${DESTDIR}/"
> # The lack of a `\' on the line ending with `&&' is not a typo, it's #
> not needed.
>
> cd $DESTDIR/patches
>
> lastupd=/path/to/LAST_UPDATED
> inst=0
>
> while read sum file; do
> if [ ${file} -nt ${lastupd} ]; then
> if [ $(openssl md5 ${file}|cut -d' ' -f2) = ${sum} ]; then
> gpg --verify ${file}.asc ${file} 2>/dev/null &&
> upgradepkg --install-new ${file} ; (( ++inst )) ||
> echo BAD sig for: ${file} >&2
> else
> echo ERROR: BAD md5 sum for: ${file} >&2
> fi
> fi
> done < grep -e ".tgz$" CHECKSUMS.md5
This doesn't work. I get a "syntax error near unexpected token `-e'"
If I pipe grep to the while (the other way around) it does work. I had to
touch the update file manually the first time, though.
>
> [ $inst -gt 0 ] && touch ${lastupd}
>
> #end script
>
> HTH
Thanks,
Roel
Roel Kluin
> if the updates are done from a cron job which is run at a time when the
> machine is shut down it will also end up being non-updated.
This is the case for my computer. I use it as a desktop computer and it's
off at irregular times.
> Another thing to consider is if you really wan't to install all patches.
> During the years there have been a number of patches which I have
> choosen not to install. Sometimes there is a warning in ChangeLog.txt
> that installing a patched application X is going to break application Y.
> At those occasion you might want to manually determine if the security
> hole in application X is more important to fix than to keep a working
> application Y. At some other few times I have found that patches has
> broken some functionality.
You have a point here, but I can take the risk on this computer.
Sounds like you have a lot of computers running and try to keep them that
way. I can undertand why you choose your approach, but its not necessary
on my computer, My situation is that I have only one, If it breaks, it's
managable to fix it. Thanks for sharing, though.
Roel
Floyd L. Davidson
>
>Sounds like you have a lot of computers running and try to keep them that
>way. I can undertand why you choose your approach, but its not necessary
>on my computer, My situation is that I have only one, If it breaks, it's
>managable to fix it. Thanks for sharing, though.
I'm not sure that is a valid way to look at it! :-)
If you boot your one computer up to do something that is
1) important, and 2) quick to do, but 3) can barely be
done in just the time you happen to have available...
you are royally screwed if it breaks!
The only part of that which I'd make automatic might be
the download, but there is *no* way I'd allow an
automatic package installation of any kind. The
download can also be put into the background, and need
not interfere with normal access (i.e., delay booting)
other than perhaps slowing down everything a bit because
the CPU is being shared until it is finished.
Upgrading to new packages is should *only* be done when
you have the time available to fix the system if it
turns out something is not compatible. You know...
like Sunday morning before anyone else gets out of bed.
Or a rainy afternoon when the picknick has been
cancelled.
But updating just as you boot up to do your last edit
on that report you know will get you a promotion? NO!
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
Martin Lefebvre
> I wrote this script to update slackware patches during boot. Maybe it's
> useful to others, are there any reasons thinkable why this shouldn't be
> done? any suggestions? TIA.
>
well, the reason why I wouldn't do it, now that I think of it, is that I
never shutdown the machine... if it reboots, then either it's because there
is a problem, or because I just upgraded the kernel, and in either
situation, I doubt I would have the patience to wait for the system to
update itself... Automatic updates are something I disagree with, as they
always manage to take place at the most inopportune time, or you miss some
of the updrades that happen.
imagine you boot your computer... and there's a fix to firefox to a totally
changed version which will, for example, corrupt your profile if you don't
go through a certain "import" procedure first... since your system started
to update while booting, and there's a good chance these updates take a long
time, you walked away from the machine to get some coffee, come back after
it's booted, fire up firefox, and you realize your bookmarks and saved
information are now gone.
I'm not saying it's something very common, but it's still a possibility I
would prefer to stay away from...
Roel Kluin
Ok, you convinced me. I'll keep it as script, and adapt it so that I can
review the patches and select which patches will be applied.
Kees Theunissen
> Steve Youngs -- Sun, 02 Sep 2007 18:15:12 +1000:
[ big snip ]
>> cd $DESTDIR/patches
>>
>> lastupd=/path/to/LAST_UPDATED
>> inst=0
>>
>> while read sum file; do
>> if [ ${file} -nt ${lastupd} ]; then
And ${file}'s timestamp is the date/time of the _release_ of the update?
_Not_ the download time? In that case you'll miss all updates that
were already released at the moment you run the script but that were
not downloaded yet by your mirror.
>> if [ $(openssl md5 ${file}|cut -d' ' -f2) = ${sum} ]; then
>> gpg --verify ${file}.asc ${file} 2>/dev/null &&
>> upgradepkg --install-new ${file} ; (( ++inst )) ||
>> echo BAD sig for: ${file} >&2
>> else
>> echo ERROR: BAD md5 sum for: ${file} >&2
>> fi
>> fi
>> done < grep -e ".tgz$" CHECKSUMS.md5
>
> This doesn't work. I get a "syntax error near unexpected token `-e'"
Yes, the "<" would cause the while-loop to read from a file named
"grep". Any additional command line parameter after this "file name"
is a syntax error.
> If I pipe grep to the while (the other way around) it does work. I had to
> touch the update file manually the first time, though.
There is still a bug in this loop which was also present in Roel's
original script. And I'm not talking about the regular expression ".tgz"
instead of "\.tgz"; this is an error but it is not likely to cause any
harm.
The wile-loop will install all recently downloaded files with a name
ending in ".tgz". Currently there are no files with such a name in
patches/source but there are such files below the source directory in
the slackware distribution. So there is some risk that *.tgz files will
appear in $DESTDIR/patches/source.
You should do something like:
grep '\./packages/.*\.tgz' CHECKSUMS.md5 | \
while read sum file; do
# do whatever you need to do
done
>
>> [ $inst -gt 0 ] && touch ${lastupd}
Personally I wouldn't bother at all about timestamps.
If I would automate my updates I would:
-- Synchronize my patches directory with a nearby mirror.
-- Check _all_ files in the patches directory and its subdirs.
The script should do all checks that I'm doing now manually:
-- run "gpg --verify" for all "*.asc" files - and that will
include CHECKSUMS.md5.asc.
-- run "md5sum -c CHECKSUMS.md5"
-- verify that all files in the patches directory and its subdirs
are mentioned in CHECKSUMS.md5
Any failures in these checks should be reported by email and
installation of any package should be skipped if there was an error
in these checks.
-- Install the updates by running (from the downloaded patches dir):
upgradepkg --install-new packages/*.tgz
Upgradepkg will take care of already installed packages so there is
no need at all to handle timestamps of packages yourself - it will
needlessly complicate your update script and possibly introduce
errors.
Regards,
Kees.
--
Kees Theunissen.
Steve Youngs
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
* Roel Kluin <rjckluin@hot_n0zpam_mail.com> writes:
> Steve Youngs -- Sun, 02 Sep 2007 18:15:12 +1000:
> Thanks for sharing your insight.
You're welcome. Apologies for the bugs I gave you.
>> Here is my version of your script. Please be aware that I didn't test
>> it, so use it at your own risk...
> I tested it and I eliminated some bugs :P
Great!
>> su $PKGUSR -c "\
>> { [ -d ${DESTDIR} ] || mkdir -p ${DESTDIR} } && rsync -q
> you have to put a smicolon after mkdir -p ${DESTDIR}
Sorry, about that. It's not needed with the shell I use (zsh), so I
didn't stop to think it it would be with bash.
>> cd $DESTDIR/patches
>>
>> lastupd=/path/to/LAST_UPDATED
>> inst=0
>>
>> while read sum file; do
>> if [ ${file} -nt ${lastupd} ]; then
>> if [ $(openssl md5 ${file}|cut -d' ' -f2) = ${sum} ]; then
>> gpg --verify ${file}.asc ${file} 2>/dev/null &&
>> upgradepkg --install-new ${file} ; (( ++inst )) ||
>> echo BAD sig for: ${file} >&2
>> else
>> echo ERROR: BAD md5 sum for: ${file} >&2
>> fi
>> fi
>> done < grep -e ".tgz$" CHECKSUMS.md5
> This doesn't work. I get a "syntax error near unexpected token `-e'"
> If I pipe grep to the while (the other way around) it does work.
Yeah, that's totally right. The < redirection expects a file. God, how
stupid was I when I wrote this?
Piping into the top of the while-loop is a fine solution. Another would
be...
candidates=$(grep "\.tgz$" CHECKSUMS.md5)
while read sum file; do
...
done < ${candidates}
Also note the modified grep... the `-e' option wouldn't be necessary,
and the `.' does need escaping. Another thing I shoulda picked up first
time.
> I had to touch the update file manually the first time, though.
Yeah, I didn't make any allowance for that.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| Genius - Is the ability to reduce |
| the complicated to the simple |
|----------------------------------<st...@youngs.au.com>---|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: The SXEmacs Project <http://www.sxemacs.org>
Comment: Eicq - The SXEmacs ICQ Client <http://www.eicq.org/>
iEYEARECAAYFAkbcwGsACgkQHSfbS6lLMAOcDgCfWDkC9IbulGuoiULkqHl93gxc
35gAoJv/0iu7HJ9L3TzMZZewZ4RTrkfU
=Je+v
-----END PGP SIGNATURE-----
Steve Youngs
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
* Kees Theunissen <theu...@rijnh.nl> writes:
> Roel Kluin wrote:
>> Steve Youngs -- Sun, 02 Sep 2007 18:15:12 +1000:
> [ big snip ]
>>> cd $DESTDIR/patches
>>>
>>> lastupd=/path/to/LAST_UPDATED
>>> inst=0
>>>
>>> while read sum file; do
>>> if [ ${file} -nt ${lastupd} ]; then
> And ${file}'s timestamp is the date/time of the _release_ of the update?
> _Not_ the download time? In that case you'll miss all updates that
> were already released at the moment you run the script but that were
> not downloaded yet by your mirror.
Not really. It could happen that if an update has a timestamp before
that of ${lastupd} _and_ still has not made it to the mirror at the time
the script is called. To guard against that I'd do two things...
if [ ${file} -nt ${lastupd} -o ! -f ${lastupd} ]; then
Which means, the first time the script is run, you will update
everything, but you gotta have a starting point. And the other thing
I'd do would be to keep the timestamp of ${lastupd} 2 or 3 days in the
past. Run it once/week from cron and I think you'd be pretty unlucky to
miss something.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| Genius - Is the ability to reduce |
| the complicated to the simple |
|----------------------------------<st...@youngs.au.com>---|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: The SXEmacs Project <http://www.sxemacs.org>
Comment: Eicq - The SXEmacs ICQ Client <http://www.eicq.org/>
iEYEARECAAYFAkbcxlYACgkQHSfbS6lLMAPPKgCg1ORFmqgTbytW3SbpSQMfs2rm
XZ0AoJ42CRBxYOyli+jSb+nBWj1mbWjO
=HdPr
-----END PGP SIGNATURE-----
Sylvain Robitaille
> Here is my version of your script. ...
In case anyone else finds it useful, the script I use is at
http://www.therockgarden.ca/software/slackware/UPGRADE.sh
I run this from cron as an unprivileged user, and it downloads any
pending updates and lets me know which *would* be installed. Then if
I'm satisfied with that I simply run the script (manually) as root, or
else I run upgradepkg as root on the packages that I do intend to
upgrade.
My UPGRADE.sh script has recently been modified to permit me to keep a
repository of package upgrades for systems running different versions of
Slackware all on the same system (some of my systems don't use
UPGRADE.sh to perform their updates, but rather a simpler script that
retrieves updated packages from the system that does run UPGRADE.sh, and
upgrades them from there, and I've recently started having version skew
(again) on my systems, so I wanted a way to have the same system
retrieve the upgraded packages, yet for different Slackware versions.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
luca
>
> I can just imagine... working, having to reboot for some reason, then
> "crap!!! my system is updating!" sounds kinda windows-updatish to me :P
using Windows is upFetish :P
Henrik Carlqvist
> In case anyone else finds it useful, the script I use is at
> http://www.therockgarden.ca/software/slackware/UPGRADE.sh
Nice script, from that script we can also see that you have the good habit
to have /usr mounted read-only. I, like most other people, am to lazy for
this and allways have /usr mounted rw.
Sylvain Robitaille
> Nice script, ...
Thanks, but I just spotted a bug in it (result of my recent modification
to accomodate a version string as an argument):
--- UPGRADE.sh.20070906 2007-09-03 01:05:02.000000000 -0400
+++ UPGRADE.sh 2007-09-06 22:15:00.000000000 -0400
@@ -8,12 +8,12 @@
# CONFIGURE:
INSTALLED_PATH=/var/log/packages
-LISTING_FILE=${DOWNLOADED_PATH}/.listing
SYSTEM_VERSION=`cat /etc/slackware-version |\
tr '[A-Z]' '[a-z]' |\
sed 's/\.[0-9]*$//; s/ /-/g'`
SLACKWARE_VERSION=${1:-${SYSTEM_VERSION}}
DOWNLOADED_PATH=/local/var/slackware/${SLACKWARE_VERSION}
+LISTING_FILE=${DOWNLOADED_PATH}/.listing
FTP_HOST=ftp.slackware.com
FTP_PATH=pub/slackware/${SLACKWARE_VERSION}/patches/packages
GPG_HOME=/home/syl/.gnupg
There's a patched version already in place at the same URL I posted
earlier (http://www.therockgarden.ca/software/slackware/UPGRADE.sh)
> from that script we can also see that you have the good habit to have
> /usr mounted read-only.
Yes. I've also recommended the same for others, both on this newsgroup
and in documentation I've written.
> I, like most other people, am to lazy for this and allways have /usr
> mounted rw.
It really isn't that much extra work. In fact, I don't consider it
sufficiently more work to justify the additional risk of having /usr
always writable.
Eef Hartman
> It really isn't that much extra work. In fact, I don't consider it
> sufficiently more work to justify the additional risk of having /usr
> always writable.
Is true, but the real work is in making "/usr" a separate partition
(and having to determine how large that will need to be, considering
"future growth"). I nowadays mostly create a 8 to 10 GB "root" partition
in which ALL of Linux (except for /opt, which is a network mount in
our installation) is located. Older machines have smaller partitions
(especially the ones that still use 40 GB "first disk"s, I don't
think there are any machines still around with a smaller disk then
that).
Correction: just checked it, an old AMD Athlon 1600+ system still only
has a 20 GB disk (but that machine will be retired in about a month,
its replacement will have 160).
--
********************************************************************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M....@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
********************************************************************
Sylvain Robitaille
> ... the real work is in making "/usr" a separate partition (and having
> to determine how large that will need to be, considering "future
> growth"). ...
How much space does Slackware's documentation indicate is needed for
an installation? Most of that will be in /usr. That's the calculation
you can work from. Add to it as much as you feel is necessary for
future growth (/usr simply doesn't grow, except with new OS releases),
and allow for having /usr/src (and /usr/local) be either a mount point
or a symlink to a writable partition.
Keith Keller
>
> How much space does Slackware's documentation indicate is needed for
> an installation? Most of that will be in /usr. That's the calculation
> you can work from. Add to it as much as you feel is necessary for
> future growth (/usr simply doesn't grow, except with new OS releases),
> and allow for having /usr/src (and /usr/local) be either a mount point
> or a symlink to a writable partition.
For CPAN users, you'd also want to allow /usr/lib/perl5 to be a mount
point/symlink (or remember to mount -w before installing from CPAN).
(Still, I'm going to test it out and see how it works; been meaning to
do so for some time.)
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
loki harfagr
> On 2007-09-07, Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
>>
>> How much space does Slackware's documentation indicate is needed for an
>> installation? Most of that will be in /usr. That's the calculation
>> you can work from. Add to it as much as you feel is necessary for
>> future growth (/usr simply doesn't grow, except with new OS releases),
>> and allow for having /usr/src (and /usr/local) be either a mount point
>> or a symlink to a writable partition.
>
> For CPAN users, you'd also want to allow /usr/lib/perl5 to be a mount
Though, that'd be a good accompanying idea to use the
upcoming winning shot to finally get rid of this kind of
"low jewelry" and finally use some language that's not just
the mongrel off a dazibao and a speedballed C0B0L highpriestess ;-)
> point/symlink (or remember to mount -w before installing from CPAN).
Best reflex would be to mount -r everytime someone comes along
with words like CPAN, Perl, update ,+\
> (Still, I'm going to test it out and see how it works; been meaning to
> do so for some time.)
>
> --keith
Ah, dreams, are my reality :D)
Sylvain Robitaille
> For CPAN users, you'd also want to allow /usr/lib/perl5 to be a mount
> point/symlink (or remember to mount -w before installing from CPAN).
Oh, yeah, and I suppose the same is true for Python when it comes
to installing modules for that as well. I almost never use Python,
so the stock Slcakware packages are fine for me for that, but Perl I
always use a locally installed version, and so completely forget that
this would be a problem, but you're right. It needs to be considered.
(just the "site_perl" directory needs to be symlinked, right?)
Keith Keller
>
>> For CPAN users, you'd also want to allow /usr/lib/perl5 to be a mount
>> point/symlink (or remember to mount -w before installing from CPAN).
>
> Oh, yeah, and I suppose the same is true for Python when it comes
> to installing modules for that as well. I almost never use Python,
> so the stock Slcakware packages are fine for me for that, but Perl I
> always use a locally installed version, and so completely forget that
> this would be a problem, but you're right. It needs to be considered.
> (just the "site_perl" directory needs to be symlinked, right?)
That sounds about right, though I haven't tested; some exotic modules
(like mod_perl, which is tightly integrated with Apache, so usually
can't be built through CPAN anyway) might write files elsewhere too.
You can tell CPAN to use a different install location, IIRC.