Re: sa-update cron failure
John Hardin wrote: > Bob Proulx wrote: > > John Hardin wrote: > > > Bob Proulx wrote: > > > > And that is also why I don't understand the move from /bin/* to > > > > /usr/bin/* and the same for lib and others. That makes the "usr" part > > > > completely useless. It would be better to move everything from > > > > /usr/bin/* up to /bin/* instead and the same for lib and the others. > > > > > >It lets you distinguish between OS utilites and application executables. > > > > How? Please say more? That one sentence is just too vague and > > ambiguous to know what you mean here. Sorry. > > OS utilities (e.g. sh, bash) go under /bin, applications (e.g. Firefox, > Inkscape) go under /usr/bin. > > That way you can mount /bin read-only unless you're performing an OS > upgrade. First let me say I am in complete agreement with you that organizing executables in that way was nice. But... The distributions are moving all of /bin/* into /usr/bin/ and Fedora has already done it. This separation you have just mentioned is disappearing for most of us and has already disappeared for many of us. My comment above was concerning an already post-moved world where everything is already moved into one directory such as on Fedora, HP-UX, some others. Bob
Re: sa-update cron failure
Am 06.02.2015 um 01:55 schrieb Martin Gregorie: On Fri, 2015-02-06 at 00:38 +0100, Reindl Harald wrote: you did not get the point there is also /usr/local/bin, /usr/local/sbin and so on You don't. You avoid name and version clashes by NOT putting distro packages on /usr/local and ONLY putting local and 3rd party developed non-standard software in /usr/local. Haven't you been paying attention? no idea what *you* are talking about i talk about UsrMove and why they did /bin -> /usr/bin and not the other way round and if you would not strip away all the context you may have not lost the track while reply IMO any properly configured system does that and also: - includes the /usr/local/* hierarchy in PATH and its chums - makes a habit of putting config files for non-standard software in /usr/local/etc* and writing it to search ., /usr/local/etc and /etc in that order for its config files. where do you move them in case of a migration? Personally, long ago I did: mkdir /home/local mv /usr/local /home/local ln -s /home/local /usr/local what has that to do with UsrMove? where /home is a separate partition that is never reformatted (unless the disk needs replacing). What do you do? Seeing that you have quite a farm I think I'd expect to find /usr/local mapped to some central, mirrored disk array for easy maintenance. /local/bin and /local/sbin is far away from any FHS anything refer /usr/local would break unconditionally Yep, and that would seem to be a sensible way to go, but then I think this sort of separation between vanilla distro packages and 'the rest' makes sense. YMMV, but I'd be interested to know why you better step back what we talked about. signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
> ICL mainframes for me: 1900 initially, then 2903 (in NYC would you > believe) and then 2966 medium rang iron into the early 80. Even the '66s > were using EDS200 and EDS640s. > At the risk of going violently off topic I'd just like to say that, should you want to see one of these large, burnt-orange beasts, the ex-Tarmac 2966 is being resurrected at the The National Museum Of Computing at Bletchley Park along with Colossus (which is complete and apparently working though I haven't a clue what its doing apart from spinning its paper tapes and making all its valves glow). http://www.tnmoc.org/ http://www.bletchleypark.org.uk/ Martin
Tales of the greybeards (was Re: sa-update cron failure)
On Fri, 06 Feb 2015 01:48:53 +
Martin Gregorie wrote:
> ICL mainframes for me: 1900 initially, then 2903 (in NYC would you
> believe) and then 2966 medium rang iron into the early 80. Even the
> '66s were using EDS200 and EDS640s.
Oooh, are we comparing greybeards? (I don't have a beard any more...)
My first computer was a TRS-80 Color Computer ("CoCo"), the original
grey model. I learned to program in 6809 assembly around 1981 after
I got fed up with the limitations of BASIC.
It was an awesome machine... really a bunch of horrible hacks to save
hardware and ROM space.
The joysticks had potentiometers on each axis. The position was
calculated by a successive-approximation A-to-D converter implemented
in software! The D-to-A part was a set of six discrete resistors in
parallel connected to a buffer and a comparator. The A-to-D part was
done in six steps by flipping each bit from MSB to LSB and checking
the output of the comparator. The same D-to-A hack drove the cassette
input and the ROM had a sine-wave table to generate 1200 or 2400Hz tones
on the cassette to save programs.
When I finally got a disk drive and looked at the disk ROM, the most
awful hack of all was revealed: The CPU was too slow to actually poll
the disk controller for new data... the conditional branch consumed
too many clock cycles. So CPU ran in an infinite loop reading data
from the controller. The CPU would be suspended by a hardware signal
from the controller until data was ready. When all data had been
read, the controller would raise an interrupt, whose handler would
munge the stack to break out of the infinite loop... a sort of early
version of siglongjmp()
The ROMs were programmed by Microsoft, so it's even conceivable that Mr. Gates
had some code in there! :)
*sigh* the bad old days... awfully fun.
> > PS. Still under 50 :)
Me too, barely.
Regards,
David.
Re: sa-update cron failure
On Thu, 2015-02-05 at 20:02 -0500, Rick Macdougall wrote: > Hi, > > First HPUX 900 certified admin in Canada circa 1982. I too remember those > days. > ICL mainframes for me: 1900 initially, then 2903 (in NYC would you believe) and then 2966 medium rang iron into the early 80. Even the '66s were using EDS200 and EDS640s. > PS. Still under 50 :) > That would be nice! Martin
Re: sa-update cron failure
Hi, First HPUX 900 certified admin in Canada circa 1982. I too remember those days. Regards, Rick PS. Still under 50 :) Sent from my iPad > On Feb 5, 2015, at 7:37 PM, Martin Gregorie wrote: > >> On Thu, 2015-02-05 at 16:06 -0700, Bob Proulx wrote: >> >> Not quite. It was due to the physically small sizes of the media >> available at the time. Therefore by necessity what would fit would >> fit on the root disk and then the system would bootstrap itself to the >> full system with more disks. > Yep. UNIX was around from the time when 60 MB disks were quite > acceptable on a mainframe and 640 MB was application designer heaven. I > know: I was there. In fact, a collection of smaller disks were preferred > to one big one because, with the slow rotation speeds of the time (2800 > rpm) having less data storage per head meant faster data access. > > > > Martin > > PS: Sorry: but I couldn't resist this one. > > >
Re: sa-update cron failure
On Fri, 2015-02-06 at 00:38 +0100, Reindl Harald wrote: > > you did not get the point > there is also /usr/local/bin, /usr/local/sbin and so on > You don't. You avoid name and version clashes by NOT putting distro packages on /usr/local and ONLY putting local and 3rd party developed non-standard software in /usr/local. Haven't you been paying attention? IMO any properly configured system does that and also: - includes the /usr/local/* hierarchy in PATH and its chums - makes a habit of putting config files for non-standard software in /usr/local/etc* and writing it to search ., /usr/local/etc and /etc in that order for its config files. > where do you move them in case of a migration? > Personally, long ago I did: mkdir /home/local mv /usr/local /home/local ln -s /home/local /usr/local where /home is a separate partition that is never reformatted (unless the disk needs replacing). What do you do? Seeing that you have quite a farm I think I'd expect to find /usr/local mapped to some central, mirrored disk array for easy maintenance. > /local/bin and /local/sbin is far away from any FHS > anything refer /usr/local would break unconditionally > Yep, and that would seem to be a sensible way to go, but then I think this sort of separation between vanilla distro packages and 'the rest' makes sense. YMMV, but I'd be interested to know why. Martin
Re: sa-update cron failure
On Thu, 2015-02-05 at 16:06 -0700, Bob Proulx wrote: > Not quite. It was due to the physically small sizes of the media > available at the time. Therefore by necessity what would fit would > fit on the root disk and then the system would bootstrap itself to the > full system with more disks. > Yep. UNIX was around from the time when 60 MB disks were quite acceptable on a mainframe and 640 MB was application designer heaven. I know: I was there. In fact, a collection of smaller disks were preferred to one big one because, with the slow rotation speeds of the time (2800 rpm) having less data storage per head meant faster data access. Martin PS: Sorry: but I couldn't resist this one.
Re: sa-update cron failure
On Thu, 2015-02-05 at 14:50 -0700, Bob Proulx wrote: > I think it should be /bin/sh because standard is better than better. > They are producing gratuitous system differences for no good reason. > If you're using the RedHat Linux or its clones you may have noticed that /bin/bash and /usr/bin/sh both resolve to bash. Personally, I don't mind: I prefer bash to sh and am quite happy with systemd. However, I do think that removing ksh and csh from the default setup is going too far. I see that ksh is now in Fedora 'extras' but csh has vanished forever. Did anybody still use it? I never did. > And that is also why I don't understand the move from /bin/* to > /usr/bin/* and the same for lib and others. That makes the "usr" part > completely useless. It would be better to move everything from > /usr/bin/* up to /bin/* instead and the same for lib and the others. > I think they are moving things in the wrong direction. The primary > location is /bin and /usr/bin was simply the secondary overflow > location. But now they have lost the primary location and only have > the secondary. That is the wrong direction. > Can't disagree. Its apparently a unilateral decision rammed through by Lennart Poettering because it assumes, on apparently no evidence at all, that everybody has huge disks and that nobody will ever want to run systemd distros on the likes of RaspberryPi, or Beagleboards. I've got news for him > But of course this is a topic for other places not here. Sigh. > Yep. I'll shut up now. Martin
Re: sa-update cron failure
On Thu, 5 Feb 2015, Bob Proulx wrote: John Hardin wrote: Bob Proulx wrote: And that is also why I don't understand the move from /bin/* to /usr/bin/* and the same for lib and others. That makes the "usr" part completely useless. It would be better to move everything from /usr/bin/* up to /bin/* instead and the same for lib and the others. It lets you distinguish between OS utilites and application executables. How? Please say more? That one sentence is just too vague and ambiguous to know what you mean here. Sorry. OS utilities (e.g. sh, bash) go under /bin, applications (e.g. Firefox, Inkscape) go under /usr/bin. That way you can mount /bin read-only unless you're performing an OS upgrade. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Programming is an art form that fights back. -- Kevin S. Gallagher --- 7 days until Abraham Lincoln's and Charles Darwin's 206th Birthdays
Re: sa-update cron failure
Am 06.02.2015 um 00:06 schrieb Bob Proulx: Reindl Harald wrote: complete nonsense you can not move anything below /usr/ in the rootfs and if it only because /usr/local and only move the contents of /usr/bin/ around breaks most setups and shebangs - get rid of /bin and /sbin while place symlinks below / don't inavlidate any existing reference Complete nonsense. There are only a very few commands that must exist in /usr/bin such as /usr/bin/env which must be accessible there. Almost no other program is required to be reached by the /usr/bin path. Any program that hard codes in the full path was never portable before. I can't tell you how many times I ran into porting issues because different systems had different binaries in /bin versus /usr/bin and yet someone hard coded the full path. Relying upon those locations was always wrong. well, and now that /bin is a symlink to /usr/bin and the same for /sbin to /usr/sbin voila all that hardcoded paths will work from one moment to the next Moving programs out of /usr/bin into /bin would not break any portable program you did not get the point there is also /usr/local/bin, /usr/local/sbin and so on where do you move them in case of a migration? /local/bin and /local/sbin is far away from any FHS anything refer /usr/local would break unconditionally with /bin symlinks to /usr/bin you just need to mobe anything in /bin to /usr/bin and replace dir directory with a symlink, any other path will work uninterrupted as before dracut had a option to do that at boot and i maintain a lot of systems which applied the UsrMove years ofter setup due a dist-upgrade - the direction you have in your mind would not have been possiblk that way signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
Reindl Harald wrote: > schrieb Bob Proulx: > >They are producing gratuitous system differences for no good reason. > > not true - hence the symlink and "they" are in the meantime not only fedora, > google will show > > >And that is also why I don't understand the move from /bin/* to > >/usr/bin/* and the same for lib and others. That makes the "usr" part > >completely useless > > maybe you should read the page i linked > https://fedoraproject.org/wiki/Features/UsrMove#Current_status > > the UsrMove is *not new* , happened years ago and happend on other unix > variants long before fedora while other Linux distributions followed in the > meantime I never said it was new. HP-UX did this way back in version 11 way back in the day and I think Solaris or others also did something like this too. This isn't new. It isn't even specific to GNU/Linux distributions. Fedora is a late arrival to the scene with this. I said it creates gratuitous system differences for no good reason. Unless every system moves everything to /usr/bin then it will never be a standard or portable thing to do /usr/bin/bash (where "bash" may be replaced with any other program from there) for example. As long as there exists one legacy system without then it is a "gratuitous" difference. Someone will run "which foo" and find foo in /usr/bin/foo and then will hard code that into some software. And yet on another system it will remain in /bin/foo and that hard coded path won't work on both systems. That is bad. And the descriptive word "good" is subjective without any objective measurement (a weasel word) that also cannot be refuted easily. This is not a good thing to do. It is without good reason. > >It would be better to move everything from > >/usr/bin/* up to /bin/* instead and the same for lib and the others. > >I think they are moving things in the wrong direction. The primary > >location is /bin and /usr/bin was simply the secondary overflow > >location. But now they have lost the primary location and only have > >the secondary. That is the wrong direction. > > complete nonsense > > you can not move anything below /usr/ in the rootfs and if it only because > /usr/local and only move the contents of /usr/bin/ around breaks most setups > and shebangs - get rid of /bin and /sbin while place symlinks below / don't > inavlidate any existing reference Complete nonsense. There are only a very few commands that must exist in /usr/bin such as /usr/bin/env which must be accessible there. Almost no other program is required to be reached by the /usr/bin path. Any program that hard codes in the full path was never portable before. I can't tell you how many times I ran into porting issues because different systems had different binaries in /bin versus /usr/bin and yet someone hard coded the full path. Relying upon those locations was always wrong. Moving programs out of /usr/bin into /bin would not break any portable program. It might break some badly written software. That would be a good thing because those portability problems would get exposed and would get fixed. And the fix for those is a trivial removal of the full hard coded path from the string improving the quality of the software. As to /usr/lib is there any reason it needs to be at that location? The user should never see that location. It is purely an internal implementation detail. There is no reason libraries could not be installed in /lib instead. I had a hard time reading your sentence and I did not understand how /usr/local fits into it. I didn't say anything about it. > /bin was for cases with /usr on a sepearte partition to contain only the > minimal tools for basic admin tasks and that never worked really well > because missing pieces and not much testing for that cases in real > operations Not quite. It was due to the physically small sizes of the media available at the time. Therefore by necessity what would fit would fit on the root disk and then the system would bootstrap itself to the full system with more disks. Since there was space on /usr it naturally was where things overflowed. Who here today hasn't overflowed into the current /home for something or another? It worked really well at the time that it was needed to be used. The problem was that it was forced by physical necessity. It was never logically needed. Therefore people have always forgotten and accidentally created problems. Such as using grep with PCRE libraries in /usr/lib before /usr was mounted and things like that. Because it wasn't logically needed people have been working against it forever. > it don't help you much that the teory is fine when tools are simply not > working in emergency mode because needed pieces are not mounted Non-sequitur. > >But of course this is a topic for other places not here. Sigh. > > indeed Sigh. Bob
Re: sa-update cron failure
John Hardin wrote: > Bob Proulx wrote: > > And that is also why I don't understand the move from /bin/* to > > /usr/bin/* and the same for lib and others. That makes the "usr" part > > completely useless. It would be better to move everything from > > /usr/bin/* up to /bin/* instead and the same for lib and the others. > > It lets you distinguish between OS utilites and application executables. How? Please say more? That one sentence is just too vague and ambiguous to know what you mean here. Sorry. Bob
Re: sa-update cron failure
On Thu, 5 Feb 2015, Bob Proulx wrote: And that is also why I don't understand the move from /bin/* to /usr/bin/* and the same for lib and others. That makes the "usr" part completely useless. It would be better to move everything from /usr/bin/* up to /bin/* instead and the same for lib and the others. It lets you distinguish between OS utilites and application executables. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Homeland Security: Specializing in Tactical Band-aids for Strategic Problems. -- Eric K. in Bruce Schneier's blog --- 7 days until Abraham Lincoln's and Charles Darwin's 206th Birthdays
Re: sa-update cron failure
Am 05.02.2015 um 22:50 schrieb Bob Proulx: Reindl Harald wrote: schrieb Bob Proulx: Seeing SHELL=/usr/bin/bash I must comment that the setting is quite unusual. It would normally be /bin/sh. Or on some systems be /bin/bash. It is quite unusual to see /usr/bin/bash there it was /bin/bash in the past but why should i define a path pointing to a symlink when i have no single setup to maintain not have /bin as symlink to /usr/bin and that won't change in the futrue, RHEL7 is at the same state https://fedoraproject.org/wiki/Features/UsrMove I think it should be /bin/sh because standard is better than better. the OS defaults are still /bin/sh i don't care about defaults They are producing gratuitous system differences for no good reason. not true - hence the symlink and "they" are in the meantime not only fedora, google will show And that is also why I don't understand the move from /bin/* to /usr/bin/* and the same for lib and others. That makes the "usr" part completely useless maybe you should read the page i linked https://fedoraproject.org/wiki/Features/UsrMove#Current_status the UsrMove is *not new* , happened years ago and happend on other unix variants long before fedora while other Linux distributions followed in the meantime It would be better to move everything from /usr/bin/* up to /bin/* instead and the same for lib and the others. I think they are moving things in the wrong direction. The primary location is /bin and /usr/bin was simply the secondary overflow location. But now they have lost the primary location and only have the secondary. That is the wrong direction. complete nonsense you can not move anything below /usr/ in the rootfs and if it only because /usr/local and only move the contents of /usr/bin/ around breaks most setups and shebangs - get rid of /bin and /sbin while place symlinks below / don't inavlidate any existing reference /bin was for cases with /usr on a sepearte partition to contain only the minimal tools for basic admin tasks and that never worked really well because missing pieces and not much testing for that cases in real operations it don't help you much that the teory is fine when tools are simply not working in emergency mode because needed pieces are not mounted But of course this is a topic for other places not here. Sigh. indeed signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
Reindl Harald wrote: > schrieb Bob Proulx: > > Seeing SHELL=/usr/bin/bash I must comment that the setting is quite > > unusual. It would normally be /bin/sh. Or on some systems be > > /bin/bash. It is quite unusual to see /usr/bin/bash there > > it was /bin/bash in the past but why should i define a path pointing to a > symlink when i have no single setup to maintain not have /bin as symlink to > /usr/bin and that won't change in the futrue, RHEL7 is at the same state > > https://fedoraproject.org/wiki/Features/UsrMove I think it should be /bin/sh because standard is better than better. They are producing gratuitous system differences for no good reason. And that is also why I don't understand the move from /bin/* to /usr/bin/* and the same for lib and others. That makes the "usr" part completely useless. It would be better to move everything from /usr/bin/* up to /bin/* instead and the same for lib and the others. I think they are moving things in the wrong direction. The primary location is /bin and /usr/bin was simply the secondary overflow location. But now they have lost the primary location and only have the secondary. That is the wrong direction. But of course this is a topic for other places not here. Sigh. Bob
Re: sa-update cron failure
Am 05.02.2015 um 18:46 schrieb LuKreme: On Feb 5, 2015, at 2:28 AM, Reindl Harald wrote: [root@srv-rhsoft:~]$ cat /etc/crontab SHELL=/usr/bin/bash PATH=/usr/bin:/usr/sbin LANG=en_GB.UTF-8 MAILTO=root HOME=/ PODCAST_THREADS=6 Ah, no, I’ve never touched /etc/crontab. I use sudo crontab -e to edit the user-level crontab for root. I consider /etc/crontab the system level crontab for root and I don’t touch that one. there is a reason for the user column :-) The PATH in /etc/crontab is not the PATH that was returned above, so it doesn’t look like the path in /etc/crontab carries forward to the other user crontabs well, i use /etc/crontab exclusive and nothing else because it has a user-column and i see no reason to deal with a dozen of files defining cronjobs left and right while a simple "cat /etc/crontab" gives me a complete overview which tasks are running under which user and when distribute-command.sh "grep 'apache' /etc/crontab" on the admin server gives me the grep over 10,20,30,100 machines - have fun doing that when every machine has other configs and snippets signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
Am 05.02.2015 um 18:44 schrieb Bob Proulx: Seeing SHELL=/usr/bin/bash I must comment that the setting is quite unusual. It would normally be /bin/sh. Or on some systems be /bin/bash. It is quite unusual to see /usr/bin/bash there it was /bin/bash in the past but why should i define a path pointing to a symlink when i have no single setup to maintain not have /bin as symlink to /usr/bin and that won't change in the futrue, RHEL7 is at the same state https://fedoraproject.org/wiki/Features/UsrMove signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
On Feb 5, 2015, at 2:28 AM, Reindl Harald wrote: > [root@srv-rhsoft:~]$ cat /etc/crontab > SHELL=/usr/bin/bash > PATH=/usr/bin:/usr/sbin > LANG=en_GB.UTF-8 > MAILTO=root > HOME=/ > PODCAST_THREADS=6 Ah, no, I’ve never touched /etc/crontab. I use sudo crontab -e to edit the user-level crontab for root. I consider /etc/crontab the system level crontab for root and I don’t touch that one. The PATH in /etc/crontab is not the PATH that was returned above, so it doesn’t look like the path in /etc/crontab carries forward to the other user crontabs. Setting the path explicitly a the top of the root user’s crontab worked. On Feb 5, 2015, at 7:03 AM, Benny Pedersen wrote: > Kevin A. McGrail skrev den 2015-02-05 14:18: >> Rather than learning more about how path and cron works, perhaps just >> symlink things like gpg to /usr/bin might be easier. Gpg is used to >> verify the authenticity of the update. > > or remove bad installers of gpg ? :=) > > http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard That may be, but both SA and gpg are installed by ports, and ports puts most everything under /usr/local which contains within it a /etc /sbin /bin /lib /libexec &c. At least I think that gig comes from gnupg1-1.4.18_2. On Feb 5, 2015, at 10:28 AM, Bob Proulx wrote: > LuKreme wrote: >> # /bin/sh >> # PATH=/bin:/usr/local/bin echo $PATH && echo $PATH >> /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin >> /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin >> >> Hm. That’s odd. >> >> Something else going on there. > > Yes. Something else is going on. :-) Damnit. Yes, of course. Grr. Here is a real test without my being stupid. As stupid. # PATH=/usr/local/bin:/usr/bin:bin whichgpg && whichgpg /usr/local/bin:/usr/bin:bin /usr/local/bin/gpg /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/local/sbin/:/sw/bin:/usr/X11R6/bin /usr/local/bin/gpg So, yes, the variable setting does NOT get carried through to the second command as you said. -- On 30 Jul 2013, Wietse Venema wrote: >Think 100MHz Pentium, 33k6 analog modem. Even I have stopped using that.
Re: sa-update cron failure
Reindl Harald wrote: > > schrieb LuKreme: > >Bob Proulx wrote: > > > The syntax "variable=value command" is a /bin/sh syntax which sets the > > > variable for just that command. In the above sa-update would get the > > > PATH setting. But then && terminates that command. > > > > I’m actually not positive that is the case. The && syntax chains > > the commands into a dependent chain (sa-update only triggers if ... > > the && does nothing than start one command only if the following with a 0 > return value and that's it - no other magic involved Right. The '&&' creates a "dependent chain" just as LuKreme said and you both say. But the point here is that the '&&' is just like ';' in that it terminates the previous command. And therefore the 'variable=value command1 && command2' affects only command1 and not command2. Since command2 is a separate command it does not get the variable=value assignment. > did you look on top of the crontab? > > normally there is PATH set and so if you install stuff to /usr/local it's > likely a good ide to have it in PATH too > > [root@srv-rhsoft:~]$ cat /etc/crontab > SHELL=/usr/bin/bash > PATH=/usr/bin:/usr/sbin That value there affects only the /etc/crontab. It won't change the value of PATH for any of the other users or crontabs. The above sets it for /etc/crontab only and all of the processes spawned from there. Since /etc/crontab usually starts run-parts for /etc/cron.daily and /etc/cron.weekly and /etc/cron.monthly then those script directories also inherit the environment settings from /etc/crontab. But other crontabs do not. Changing that PATH will not help LuKreme who is using an AT&T style '# crontab -l' /var/spool/cron/crontabs/root. The /etc/crontab is the BSD root crontab. /var/spool/crontab is the AT&T crontab. The /etc/cron.d is Vixie's crontab. vixie-cron supports all three locations and the handles the syntax differences between them transparently. Seeing SHELL=/usr/bin/bash I must comment that the setting is quite unusual. It would normally be /bin/sh. Or on some systems be /bin/bash. It is quite unusual to see /usr/bin/bash there. Bob
Re: sa-update cron failure
LuKreme wrote: > Bob Proulx wrote: > > The syntax "variable=value command" is a /bin/sh syntax which sets the > > variable for just that command. In the above sa-update would get the > > PATH setting. But then && terminates that command. > > I’m actually not positive that is the case. I am positive. :-) But please do work through the case and verify it for yourself. Learning how this works is a fundamental part of the system. > The && syntax chains the commands into a dependent chain (sa-update > only triggers if sa-update succeeded and sa-spamd restart only > triggers if both previous commands succeeded, so it would certainly > make sense that some state like setting variables is > preserver. Haven’t tested this, but it’s pretty trivial. > > # /bin/sh > # PATH=/bin:/usr/local/bin echo $PATH && echo $PATH > /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > Hm. That’s odd. > > Something else going on there. Yes. Something else is going on. :-) The $variable syntax in your above is expanded by the shell *before* the command is executed. Both of the echo $PATH are showing you the shell's value of it and not the value that you are trying to set before it. You can never set a variable for the shell process and then have the parent shell expand it. 'var=foo echo $var' will never produce a useful result. There is a little used command 'printenv' that isn't very useful normally but for just this case can be just the right tool to print the environment variable value without the shell. $ export var ; var=foo ; var=bar printenv var && printenv var bar foo Then one last thing of note here. PATH is a special shell variable. PATH in /bin/sh is an automatically exported by the shell. One must explicitly export other variables but PATH is already an exported variable. > > The next two commands sa-compile and sa-spamd would not get PATH set > > differently for them. Is that important to you? > > No idea. I don’t know about the internals of sa-compile. I can’t think of any > reason it could need gpg though. I thought the issue being discussed was that locally installed components installed in /usr/local and system installed components installed in /usr and my skimming of the problem was that PATH needed to include /usr/local/bin so that it would find locally installed components for all of the tools? No? > > # The default vixie-cron PATH is "/usr/bin:/bin", overriding the > > environment. > > PATH="/usr/local/bin:/usr/bin:/bin:/usr/games” > > That does seem better (well, minus /usr/games) That was just an example. In my I always add "/home/rwp/bin:/usr/local/bin:/usr/bin:/bin" so that I get my $HOME/bin commands too. (Note can't use $HOME because vixie-cron isn't the shell and doesn't expand variables like that so for the vixie-cron setting must use fully expanded paths.) > > Then PATH will be set for all commands started from that crontab. > > > > Personally I prefer to use a file /etc/cron.daily/spamassassin which > > then calls all of the individual programs. The /etc/cron.daily is a > > directory of scripts (not crontabs) where each script is run once > > daily one after the other. Since that is a script you can set PATH in > > that script and again it would be set for all subsequent invocations. > > That also sound good, but my crontab is actually quite > simple. Sa-update, portsnap, and some deleting aging emails. If you are often in the habit of using cron with your /usr/local (which is perfectly fine!) then I would definitely add that to the PATH for all of your crontab commands. It just makes sense to me. The alternative is to always run a script wrapper around anything you want to do. That is also a really good way to do things. Then you can set any variable such as PATH that you need in the script wrapper. Bob
Re: sa-update cron failure
On Thu, 2015-02-05 at 09:55 -0500, Kevin A. McGrail wrote: > On 2/5/2015 9:03 AM, Benny Pedersen wrote: > > Kevin A. McGrail skrev den 2015-02-05 14:18: > >> Rather than learning more about how path and cron works, perhaps just > >> symlink things like gpg to /usr/bin might be easier. Gpg is used to > >> verify the authenticity of the update. > > > > or remove bad installers of gpg ? :=) > > > > http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard > > I'd be a pot calling a kettle black because I use /usr/local all the > time to build on top of distros. > That's what its for. Anything you build yourself, whether written inhouse or from third parites. should go there, along with non-standard libraries (/usr/local/lib), config files (/usr/local/etc) and manpages (/usr/local/man) This way you can't accidentally splat a system file or have a new system file thats part of an upgrade splat one of your files. Besides, if you move /usr/local to a partition that's not usually reformatted as part of a major system upgrade and replace it with a symlink then everything in /usr/local will survive the upgrade without needing to be reinstalled or rebuilt. Martin
Re: sa-update cron failure
Am 05.02.2015 um 16:17 schrieb Kevin A. McGrail: On 2/5/2015 8:56 AM, Martin Gregorie wrote: On Thu, 2015-02-05 at 08:18 -0500, Kevin A. McGrail wrote: Rather than learning more about how path and cron works, perhaps just symlink things like gpg to /usr/bin might be easier. Gpg is used to verify the authenticity of the update. Regards, KAM On my machines anyway, gpg is in /usr/bin, so that isn't the problem unless gpg is not world executable. I'm a firm believer in E.F.Schumacher's saying "Give a man a fish and you've fed him for a day. Teach him to fish and you've fed him for life". This approach also applies to systems administration. In this case knowing how path and cron work and knowing which tools let you investigate problems in that area are sysadmin essentials, so IME helping people investigate for themselves is always preferable to simply giving them the answer. Perhaps but this is not a unix sysadmin mailing list ;-) while that may be true most people which are target of this list are sysadmin or call themself sysadmin - the ones not care about learning their basics are often a large part of abused servers sending spam so it's directly related at the end of the day signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
Am 05.02.2015 um 16:20 schrieb Benny Pedersen: Kevin A. McGrail skrev den 2015-02-05 15:55: I'd be a pot calling a kettle black because I use /usr/local all the time to build on top of distros. make install, defaults to /usr/local, but distros must not use that prefix what exactly did you not understand in "to build on top of distros"? signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
Kevin A. McGrail skrev den 2015-02-05 15:55: I'd be a pot calling a kettle black because I use /usr/local all the time to build on top of distros. make install, defaults to /usr/local, but distros must not use that prefix working with freebsd lately ? :=)
Re: sa-update cron failure
On 2/5/2015 8:56 AM, Martin Gregorie wrote: On Thu, 2015-02-05 at 08:18 -0500, Kevin A. McGrail wrote: Rather than learning more about how path and cron works, perhaps just symlink things like gpg to /usr/bin might be easier. Gpg is used to verify the authenticity of the update. Regards, KAM On my machines anyway, gpg is in /usr/bin, so that isn't the problem unless gpg is not world executable. I'm a firm believer in E.F.Schumacher's saying "Give a man a fish and you've fed him for a day. Teach him to fish and you've fed him for life". This approach also applies to systems administration. In this case knowing how path and cron work and knowing which tools let you investigate problems in that area are sysadmin essentials, so IME helping people investigate for themselves is always preferable to simply giving them the answer. Perhaps but this is not a unix sysadmin mailing list ;-)
Re: sa-update cron failure
On 2/5/2015 9:03 AM, Benny Pedersen wrote: Kevin A. McGrail skrev den 2015-02-05 14:18: Rather than learning more about how path and cron works, perhaps just symlink things like gpg to /usr/bin might be easier. Gpg is used to verify the authenticity of the update. or remove bad installers of gpg ? :=) http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard I'd be a pot calling a kettle black because I use /usr/local all the time to build on top of distros.
Re: sa-update cron failure
Kevin A. McGrail skrev den 2015-02-05 14:18: Rather than learning more about how path and cron works, perhaps just symlink things like gpg to /usr/bin might be easier. Gpg is used to verify the authenticity of the update. or remove bad installers of gpg ? :=) http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Re: sa-update cron failure
On Thu, 2015-02-05 at 08:18 -0500, Kevin A. McGrail wrote: > Rather than learning more about how path and cron works, perhaps just symlink > things like gpg to /usr/bin might be easier. Gpg is used to verify the > authenticity of the update. > Regards, > KAM > On my machines anyway, gpg is in /usr/bin, so that isn't the problem unless gpg is not world executable. I'm a firm believer in E.F.Schumacher's saying "Give a man a fish and you've fed him for a day. Teach him to fish and you've fed him for life". This approach also applies to systems administration. In this case knowing how path and cron work and knowing which tools let you investigate problems in that area are sysadmin essentials, so IME helping people investigate for themselves is always preferable to simply giving them the answer. Martin
Re: sa-update cron failure
Rather than learning more about how path and cron works, perhaps just symlink things like gpg to /usr/bin might be easier. Gpg is used to verify the authenticity of the update. Regards, KAM
Re: sa-update cron failure
On Thu, 2015-02-05 at 01:21 -0700, LuKreme wrote: > > On Feb 5, 2015, at 1:03 AM, Bob Proulx wrote: > # /bin/sh > # PATH=/bin:/usr/local/bin echo $PATH && echo $PATH > /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > Hm. That’s odd. > > Something else going on there. > Normally, setting any shell variable, including PATH, in a shell script only takes effect in that script. If you want it to affect child scripts, prefix it with 'export': export PATH=/bin:/usr/bin:/usr/local/bin Another convention that might be having an effect is that programs that are included in packages installed with your UNIX/Linux package installer are normally placed in /bin or /usr/bin but programs installed by other methods (e.g. make; make install if the program was supplied as source should be placed in /usr/local/bin). I think CPAN installs of Perl programs normally do NOT end up in /bin or /usr/bin but I could be wrong about that. These possibilities are why you were asked to run 'which xxx' as a cron script, where xxx is a program that wasn't found by sa-update. If 'which' says 'not found, try running 'locate xxx': this will find the program (and any similar names) by searching a database which references the entire filing system. If it isn't installed or its database isn't up to date, "sudo find / -name " will do the same job but it will be much slower and doesn't match similar names. Martin
Re: sa-update cron failure
Am 05.02.2015 um 09:21 schrieb LuKreme: On Feb 5, 2015, at 1:03 AM, Bob Proulx wrote: LuKreme wrote: The front actin simply calls sa-update. Do I just 16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart ? Or is there a reason not to do that? The syntax "variable=value command" is a /bin/sh syntax which sets the variable for just that command. In the above sa-update would get the PATH setting. But then && terminates that command. I’m actually not positive that is the case. The && syntax chains the commands into a dependent chain (sa-update only triggers if sa-update succeeded and sa-spamd restart only triggers if both previous commands succeeded, so it would certainly make sense that some state like setting variables is preserver. Haven’t tested this, but it’s pretty trivial. the && does nothing than start one command only if the following with a 0 return value and that's it - no other magic involved did you look on top of the crontab? normally there is PATH set and so if you install stuff to /usr/local it's likely a good ide to have it in PATH too [root@srv-rhsoft:~]$ cat /etc/crontab SHELL=/usr/bin/bash PATH=/usr/bin:/usr/sbin LANG=en_GB.UTF-8 MAILTO=root HOME=/ PODCAST_THREADS=6 signature.asc Description: OpenPGP digital signature
Re: sa-update cron failure
> On Feb 5, 2015, at 1:03 AM, Bob Proulx wrote: > > LuKreme wrote: >> The front actin simply calls sa-update. Do I just >> >> 16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update >> && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart >> >> ? >> >> Or is there a reason not to do that? > > The syntax "variable=value command" is a /bin/sh syntax which sets the > variable for just that command. In the above sa-update would get the > PATH setting. But then && terminates that command. I’m actually not positive that is the case. The && syntax chains the commands into a dependent chain (sa-update only triggers if sa-update succeeded and sa-spamd restart only triggers if both previous commands succeeded, so it would certainly make sense that some state like setting variables is preserver. Haven’t tested this, but it’s pretty trivial. # /bin/sh # PATH=/bin:/usr/local/bin echo $PATH && echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin Hm. That’s odd. Something else going on there. > The next two commands sa-compile and sa-spamd would not get PATH set > differently for them. Is that important to you? No idea. I don’t know about the internals of sa-compile. I can’t think of any reason it could need gpg though. > # The default vixie-cron PATH is "/usr/bin:/bin", overriding the environment. > PATH="/usr/local/bin:/usr/bin:/bin:/usr/games” That does seem better (well, minus /usr/games) > Then PATH will be set for all commands started from that crontab. > > Personally I prefer to use a file /etc/cron.daily/spamassassin which > then calls all of the individual programs. The /etc/cron.daily is a > directory of scripts (not crontabs) where each script is run once > daily one after the other. Since that is a script you can set PATH in > that script and again it would be set for all subsequent invocations. That also sound good, but my crontab is actually quite simple. Sa-update, portsnap, and some deleting aging emails. -- 'I really should talk to him, sir. He's had a near-death experience!' 'We all do. It's called living.'
Re: sa-update cron failure
LuKreme wrote: > The front actin simply calls sa-update. Do I just > > 16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update && > /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart > > ? > > Or is there a reason not to do that? The syntax "variable=value command" is a /bin/sh syntax which sets the variable for just that command. In the above sa-update would get the PATH setting. But then && terminates that command. The next two commands sa-compile and sa-spamd would not get PATH set differently for them. Is that important to you? Otherwise you would need to repeat the PATH setting for the second and third commands on the command line too. But there is a better way. If you are using vixie-cron (most GNU/Linux distributions do) then you can set PATH globally in the crontab. Simply set it in the crontab file. This doesn't work in traditional legacy crons but does work with vixie-cron. # The default vixie-cron PATH is "/usr/bin:/bin", overriding the environment. PATH="/usr/local/bin:/usr/bin:/bin:/usr/games" Then PATH will be set for all commands started from that crontab. Personally I prefer to use a file /etc/cron.daily/spamassassin which then calls all of the individual programs. The /etc/cron.daily is a directory of scripts (not crontabs) where each script is run once daily one after the other. Since that is a script you can set PATH in that script and again it would be set for all subsequent invocations. Bob
Re: sa-update cron failure
On Feb 4, 2015, at 9:21 PM, Kevin A. McGrail wrote: > Define your path in the cron script. The front actin simply calls sa-update. Do I just 16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart ? Or is there a reason not to do that? -- Mac OSX - Because making Unix user-friendly was easier than fixing Windows.
Re: sa-update cron failure
Define your path in the cron script. LuKreme wrote: > >> On Feb 4, 2015, at 8:34 PM, David B Funk > wrote: >> >> On Wed, 4 Feb 2015, LuKreme wrote: >> >>> On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote: Perhaps /usr/local/bin is not on PATH for the cron user? >>> >>> I don’t understand what you are saying. The crontab lists the full >path. >>> > # crontab -l |grep sa-update > 16 1 * * * /usr/local/bin/sa-update && >/usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart >> >> You are right but the things -inside- that "sa-update" script do not >have the full path for each of their tools they use. Thus the "gpg" >utility must >> be in a directory included in the $PATH variable that the script >inherits. > >Ah, right. > >The script returns > >PATH=/usr/bin:/bin > >Seems the sa-update script should be able to figure out the location >for gpg. > >Now what? > >-- >A good friend will come and bail you out of jail but a true friend will >be sitting next to you saying, "Dang, that was fun." Regards, KAM
Re: sa-update cron failure
> On Feb 4, 2015, at 8:34 PM, David B Funk wrote: > > On Wed, 4 Feb 2015, LuKreme wrote: > >> On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote: >>> Perhaps /usr/local/bin is not on PATH for the cron user? >> >> I don’t understand what you are saying. The crontab lists the full path. >> # crontab -l |grep sa-update 16 1 * * * /usr/local/bin/sa-update && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart > > You are right but the things -inside- that "sa-update" script do not have the > full path for each of their tools they use. Thus the "gpg" utility must > be in a directory included in the $PATH variable that the script inherits. Ah, right. The script returns PATH=/usr/bin:/bin Seems the sa-update script should be able to figure out the location for gpg. Now what? -- A good friend will come and bail you out of jail but a true friend will be sitting next to you saying, "Dang, that was fun."
Re: sa-update cron failure
On Wed, 4 Feb 2015, LuKreme wrote:
On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote:
Perhaps /usr/local/bin is not on PATH for the cron user?
I don’t understand what you are saying. The crontab lists the full path.
# crontab -l |grep sa-update
16 1 * * * /usr/local/bin/sa-update && /usr/local/bin/sa-compile &&
/usr/local/etc/rc.d/sa-spamd restart
You are right but the things -inside- that "sa-update" script do not have the
full path for each of their tools they use. Thus the "gpg" utility must
be in a directory included in the $PATH variable that the script inherits.
Try this; create a test script "/usr/local/bin/sa-path-check"
and in that script put a "which gpg" command and run that as a
cron job and see what output it generates.
(you could also put a "echo $PATH" in the script to see exactly
what the path actuall is for that environment.)
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: sa-update cron failure
On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote: > Perhaps /usr/local/bin is not on PATH for the cron user? I don’t understand what you are saying. The crontab lists the full path. >> # crontab -l |grep sa-update >> 16 1 * * * /usr/local/bin/sa-update && /usr/local/bin/sa-compile && >> /usr/local/etc/rc.d/sa-spamd restart -- Happy Jack wasn't tall, but he was a man
Re: sa-update cron failure
Perhaps /usr/local/bin is not on PATH for the cron user?
On 2/4/2015 10:50 AM, LuKreme wrote:
Cron is sending me an error:
error: gpg required but not found! It is not recommended, but you can use
"sa-update" with the --no-gpg to skip the verification.
However, if I run sa-update -D from the command line, it succeeds:
Feb 4 08:48:26.885 [48573] dbg: logger: adding facilities: all
Feb 4 08:48:26.885 [48573] dbg: logger: logging level is DBG
Feb 4 08:48:26.885 [48573] dbg: generic: SpamAssassin version 3.4.0
Feb 4 08:48:26.885 [48573] dbg: generic: Perl 5.020001, PREFIX=/usr/local,
DEF_RULES_DIR=/usr/local/share/spamassassin,
LOCAL_RULES_DIR=/usr/local/etc/mail/spamassassin,
LOCAL_STATE_DIR=/var/db/spamassassin
Feb 4 08:48:26.885 [48573] dbg: config: timing enabled
Feb 4 08:48:26.886 [48573] dbg: config: score set 0 chosen.
Feb 4 08:48:26.893 [48573] dbg: generic: sa-update version svn1475932
Feb 4 08:48:26.893 [48573] dbg: generic: using update directory:
/var/db/spamassassin/3.004000
Feb 4 08:48:27.425 [48573] dbg: diag: perl platform: 5.020001 freebsd
Feb 4 08:48:27.425 [48573] dbg: diag: [...] module installed: Digest::SHA,
version 5.88
Feb 4 08:48:27.425 [48573] dbg: diag: [...] module installed: HTML::Parser,
version 3.71
Feb 4 08:48:27.425 [48573] dbg: diag: [...] module installed: Net::DNS,
version 0.82
Feb 4 08:48:27.425 [48573] dbg: diag: [...] module installed: NetAddr::IP,
version 4.069
Feb 4 08:48:27.425 [48573] dbg: diag: [...] module installed: Time::HiRes,
version 1.9726
Feb 4 08:48:27.425 [48573] dbg: diag: [...] module installed: Archive::Tar,
version 1.96
Feb 4 08:48:27.425 [48573] dbg: diag: [...] module installed: IO::Zlib,
version 1.10
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module not installed: Digest::SHA1
('require' failed)
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module installed: MIME::Base64,
version 3.14
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module installed: DB_File, version
1.831
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module installed: Net::SMTP,
version 2.33
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module installed: Mail::SPF,
version v2.009
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module not installed: Geo::IP
('require' failed)
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module not installed:
Razor2::Client::Agent ('require' failed)
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module installed: IO::Socket::IP,
version 0.36
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module installed:
IO::Socket::INET6, version 2.72
Feb 4 08:48:27.426 [48573] dbg: diag: [...] module installed: IO::Socket::SSL,
version 2.009
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module installed: Compress::Zlib,
version 2.064
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module installed: Mail::DKIM,
version 0.4
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module installed: DBI, version
1.633
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module installed: Getopt::Long,
version 2.42
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module not installed:
LWP::UserAgent ('require' failed)
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module installed: HTTP::Date,
version 6.02
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module installed: Encode::Detect,
version 1.01
Feb 4 08:48:27.427 [48573] dbg: diag: [...] module not installed:
Net::Patricia ('require' failed)
Feb 4 08:48:27.428 [48573] dbg: gpg: Searching for 'gpg'
Feb 4 08:48:27.428 [48573] dbg: util: current PATH is:
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/syth/bin
Feb 4 08:48:27.428 [48573] dbg: util: executable for gpg was found at
/usr/local/bin/gpg
Feb 4 08:48:27.429 [48573] dbg: gpg: found /usr/local/bin/gpg
Feb 4 08:48:27.429 [48573] dbg: gpg: release trusted key id list:
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
0C2B1D7175B852C64B3CDC716C55397824F434CE
Feb 4 08:48:27.430 [48573] dbg: channel: attempting channel
updates.spamassassin.org
Feb 4 08:48:27.430 [48573] dbg: channel: using existing directory
/var/db/spamassassin/3.004000/updates_spamassassin_org
Feb 4 08:48:27.430 [48573] dbg: channel: channel cf file
/var/db/spamassassin/3.004000/updates_spamassassin_org.cf
Feb 4 08:48:27.430 [48573] dbg: channel: channel pre file
/var/db/spamassassin/3.004000/updates_spamassassin_org.pre
Feb 4 08:48:27.430 [48573] dbg: channel: metadata version = 1655961, from file
/var/db/spamassassin/3.004000/updates_spamassassin_org.cf
Feb 4 08:48:27.611 [48573] dbg: dns: 0.4.3.updates.spamassassin.org =>
1655961, parsed as 1655961
Feb 4 08:48:27.611 [48573] dbg: channel: current version is 1655961, new
version is 1655961, skipping channel
Feb 4 08:48:27.612 [48573] dbg: diag: updates complete, exiting with code 1
# which sa-update
/usr/local/bin/sa-update
# crontab -l |grep sa-update
16 1 * * * /usr/local/bin/sa-update && /usr/local/bin/sa-compile &&
/usr/local/etc/rc.d/sa-spamd restart
