A great method for keeping Slackware up-to-date...without slackpkg.

Lufbery · 01-30-2010, 10:23 AM

Quote:

Originally Posted by grissiom

@Lufbery

Once I've know your purpose on this project, my aim being at here is not to start wars.(Do we? No, I think

) I just want to see some technical details. Your script is a good start and may end of something useful.

Grission,

All comments are welcome. I'm learning a lot here.

I agree with your previous comments, I just wanted you to know that this is a special-purpose script to keep -stable up-to-date.

Regards,

Lufbery · 01-30-2010, 10:27 AM

Okay folks,

Here's the latest version of my script that works by keeping a local mirror. It has MD5 checking, and in my tests so far, it works well. I created an error by adding some text to one of the packages text files and the script exits correctly.

Code:

#!/bin/bash
#update_slackware.sh
#Note: run this script as root from the local ./patches directory.

#Synchronize the local mirror with the remote mirror:
lftp -c "open ftp://my-favorite-mirror/slackware-version/patches/ ; mirror -e -n packages"

#Download the most recent CHECKSUMS.md5 file:
rm -f CHECKSUMS.md5
lftp -c get ftp://my-favorite-mirror/slackware-version/patches/CHECKSUMS.md5

#Check for MD5 checksum errors and exit if some are found.
if grep "\./packages/" CHECKSUMS.md5 | md5sum -c | grep -v OK$
   then echo "Script aborting. Try manually downloading the file(s) listed above"
   exit 1
fi

#Upgrade Slackware with downloaded packages:
echo "No errors found; updating with new packages."
upgradepkg ./packages/*.txz

#Find configuration files that need attention:
echo "Checking for new configuration files:"
find /etc -name "*.new"

This works and I'm pretty happy.

I'm thinking of adding a routine where the grep error becomes a variable and the script attempts to re-download those files before continuing.

Regards,

agi93 · 01-30-2010, 11:42 AM

This is awesome! I love slackpkg and all, but after using slackware for a little while, I'm really starting to appreciate the simple, elegant, manual way of doing things. This way just seems right somehow.

Lufbery · 01-30-2010, 10:07 PM

Quote:

Originally Posted by agi93

This is awesome! I love slackpkg and all, but after using slackware for a little while, I'm really starting to appreciate the simple, elegant, manual way of doing things. This way just seems right somehow.

Thanks for the vote of confidence.

If anyone uses this script, or H_TeXMeX_H's version of it, please let us know.

Regards,

grissiom · 01-31-2010, 02:24 AM

@Lufbery

Maybe you can use a list to store the error message from grep:

Code:

corrupted_pkg=($(grep "\./packages/" CHECKSUMS.md5 | md5sum -c | grep -v OK$))

than do some thing with it:

Code:

for i in ${corrupted_pkg[@]}; do ... done

Besides, some .new files doesn't lay on /etc. For example, /usr/lib{64}/man.conf.new

find / -name "*.new" is pain. How to handle them?

H_TeXMeX_H · 01-31-2010, 05:03 AM

Well, personally I don't like a lot of automation in scripts, there is a limit to what is useful. If you start making lots of loops so that you can somehow try to succeed in what you are doing, you may just end up wasting the user's time and your own (in making it). If something fails, just tell the user what failed, usually I let the programs speak for themselves, I don't hide the md5sum output, I like to see to make sure everything went good, then let the user decide what to do.

Stroker · 01-31-2010, 01:11 PM

I am surprised at how many believe md5 checking is adequate.

md5 only tests file transfer integrity. Mirrors can get cracked!(pun intended)

gpg signatures test file integrity and authenticity.

Slackpkg uses both md5 sums and asc sigs by default. Which is fine, but probably unnecessary.

Slackpkg actually does crazy cross checks: asc against md5, md5 against asc, md5 against pkg, asc against pkg. That may be overkill, but when it comes to system security I think overkill is always better, so I'm not complaining just stating the facts.

GrapefruiTgirl · 01-31-2010, 01:48 PM

@ Lufbery,

since you asked earlier, there are a couple things suggested above which are not POSIX, in case you are interested:

1) path substitution, such as, for example:

Code:

mv /some/path/file{this,that} /some/other/place

2) arrays. arrays are a big bad woof

and I believe the following qualifies as an array:

Code:

for i in ${corrupted_pkg[@]}; do ... done

Sasha

H_TeXMeX_H · 01-31-2010, 01:55 PM

Quote:

Originally Posted by Stroker

I am surprised at how many believe md5 checking is adequate.

md5 only tests file transfer integrity. Mirrors can get cracked!(pun intended)

gpg signatures test file integrity and authenticity.

Slackpkg uses both md5 sums and asc sigs by default. Which is fine, but probably unnecessary.

Slackpkg actually does crazy cross checks: asc against md5, md5 against asc, md5 against pkg, asc against pkg. That may be overkill, but when it comes to system security I think overkill is always better, so I'm not complaining just stating the facts.

You're right, it's better to use both. Well, I guess I can implement that, but I don't care all that much. I'll see what I can do.

Couldn't they also theoretically get the key used to sign the packages ... or replace it with their own, then sign the packages. Admittedly, it's much harder, but not impossible (I believe it happened to Red Hat once).

fancylad · 01-31-2010, 02:06 PM

Just out of curiosity, why are people so concerned with /bin/sh being a fully POSIX compliant shell? Are you hoping to update slackware packages on Solaris system? A truly POSIX shell is fairly antiquated (compared to bash anyways) and, as far as I am aware of, bash is the de facto shell on *all* Linux distros. This is Slackware after all so I know that /bin/sh is a sym link to bash. I think that this may not be the case for Ubuntu which I believe has /bin/sh as a sym link to dash.

I know that shells like dash are smaller, lighter, slightly faster etc, but, for the most part, these aren't embedded systems and the boot time using bash and dash would be negligable. (I haven't bench marked this, but if someone has done this on their system I'd like to see the results).

I'm not trying to bash someone (pun definitely intended) for wanting to have /bin/sh be a fully compatible POSIX shell but this is 2010 after all and, in my opinion, shells like Bash *should* be the standard, POSIX or otherwise. I mean, not supporting arrays? That just makes things way too awkward.

GrapefruiTgirl · 01-31-2010, 02:16 PM

[OFFtopic]
I don't believe that most people are concerned with POSIX compliance in their daily lives. I just a took a personal interest in it a while back, while "porting" (repairing, to be more accurate) a project of mine so it would be more portable.

Since that time, I also POSIXified all my Slackware boot scripts, which inspired another Slack user/contributor/whatever he is

(tuxdev) to post a complete (??) set of Slackware init scripts on gitweb, in case anyone else wanted to use a smaller, faster shell as /bin/sh on Slackware as I am doing (I'm using Dash as /bin/sh).

Standards exist so people can do things more easily across platforms. IMHO, the fact that Bash's POSIX mode is not POSIX compliant, is somewhat stupid. However, what I think about this is not really important, it's just my opinion. But if someone is going to claim to adhere to a standard, and then doesn't but still claims to, it makes things difficult for people to use the program, when it doesn't work as expected (or at all) in the prescribed environment.

Ubuntu uses Bash as /bin/sh, but it used Dash as it's boot shell, in which its init scripts are run. This is to speed up the relatively loooong boot process of Ubuntu.

On my system, using Dash as /bin/sh does actually increase performance/speed of shell applications running in it, by a significant factor. And, if a person is interested in running Slack on a low-space or low-memory system, Dash is 1/7th the size of Bash.

And you are correct, Bash is the most commonly used interactive shell on most or all Linux systems.

[/OFFtopic]

H_TeXMeX_H · 01-31-2010, 02:19 PM

It is important, because there are many variants of the bourne-shell. Supposedly they should all be able to be linked to '/bin/sh' and work. Say you only wanted to use ksh and you linked it to '/bin/sh', technically it should work properly no matter what you wrote in the script. This is only in theory tho, I'm not sure how seriously most projects take POSIX compliance.

mRgOBLIN · 01-31-2010, 02:49 PM

Quote:

Originally Posted by H_TeXMeX_H

Couldn't they also theoretically get the key used to sign the packages ... or replace it with their own, then sign the packages. Admittedly, it's much harder, but not impossible (I believe it happened to Red Hat once).

Well in theory I guess it is possible but highly unlikely.

They would need to get the private key and know the pass-phrase for it before they could sign anything with it. One benefit of having a small development team is that not many people need or have access to this.

Lufbery · 01-31-2010, 08:40 PM

Quote:

Originally Posted by Stroker

I am surprised at how many believe md5 checking is adequate.

md5 only tests file transfer integrity. Mirrors can get cracked!(pun intended)

gpg signatures test file integrity and authenticity.

Good points. I'll see about adding something like the test from GazL in this previous post.

Regards,

Richard Cranium · 01-31-2010, 11:07 PM

Well, there's always slackroll. It handles kernel upgrades correctly as well as glibc-solibs, sed and pkgtools upgrades. It allows you to examine the changelog updates before you do anything.

http://rg3.github.com/slackroll/

If you try it, only use http:// mirrors. FTP sites will work, but much more slowly. Much more slowly.