non-root syslogd?
Has anyone investigated what would be necessary to get a non-root syslogd working under Debian? It seems like this would be a good thing, but obviously there have to be some tricky bits, else it would have happened already. :) It seems like the steps would be: Add a user for syslog to run as. chown /var/log to be syslog.adm Modify logrotate configs to set ownership properly. It looks like syslogd, syslog-ng, etc would have to be patched to setup /dev/log and open UDP 514, then setuid to the syslog user. Is this worth working on? Has anybody already done this? M pgpUMzKgwrP6k.pgp Description: PGP signature
Re: FYI: www.infrastructures.org
Karl M. Hegbloom said on Tue, Jul 22, 2003 at 02:01:19AM -0700: > http://www.infrastructures.org/papers/bootstrap/bootstrap.html While this is a good paper, and there are lots of interesting ideas contained within it that map well to Debian (I've got 50 or so Debian boxes in a configuration inspired by the above paper, it's unclear why you posted the link here. However, if you're a sysadmin, and haven't read the above paper, it's probably worth your time. M pgph5cKeh3q1x.pgp Description: PGP signature
Re: Usefulness of SSMTP [Was: Should MUA only Recommend mail-transfer-agent?]
Joe Wreschnig said on Wed, Aug 06, 2003 at 04:39:10PM -0500: > > And is a much better choice than expecting every user to locally > > configure smtp settings in the MUA. Lack of direct-SMTP support in mutt > > is a good thing. > > SSMTP is not acceptable for those of us that use SMTP AUTH+TLS, unless > it supports those (it didn't, last time I looked). In fact, there don't > appear to be any "dumb" MTAs (like ssmtp or nullmailer) that support TLS > and SMTP authentication. This is why I can't use Mutt anymore. ssmtp in unstable supports TLS and certificate based AUTH (so you can authenticate on a per machine basis for relay). It appears to have AUTH CRAM-MD5 support, but it's unclear if that's distributable (according to comments in the source). It also has AUTH LOGIN support (on a per user basis, via the -au and -ap command line options). So, you could use mutt, if you wanted to backport ssmtp from unstable (which I have done, and it's pretty easy to do). M pgpq7xg4zr6Wb.pgp Description: PGP signature
Re: Usefulness of SSMTP [Was: Should MUA only Recommend mail-transfer-agent?]
Joe Wreschnig said on Wed, Aug 06, 2003 at 05:43:49PM -0500: > Interesting. I'm running unstable, but I can't find instructions on > enabling TLS anywhere (nor does SSMTP seem to link to any TLS > libraries). I see mention of it in the README (specifically, only a > credit for it), but not the manual page, nor the configuration file, nor > README.Debian. ssmtp.conf has no manual page. > > If it is there, it's damned well hidden. Whups. Yes, it is damned well hidden. Apparently, the Debian package of ssmtp doesn't enable TLS, and ssmtp.conf doesn't have a man page. I rebuilt my own with TLS enabled. I'm not sure why ssmtp has TLS disabled by default; perhaps a bug should be filed? It seems like it would provide all of the needed outgoing MTA functionality without requiring a daemon. M pgp5N5xe370wt.pgp Description: PGP signature
Re: Usefulness of SSMTP [Was: Should MUA only Recommend mail-transfer-agent?]
Joe Wreschnig said on Wed, Aug 06, 2003 at 06:32:14PM -0500: > On Wed, 2003-08-06 at 18:04, Mark Ferlatte wrote: > > I'm not sure why ssmtp has TLS disabled by default; perhaps a bug should be > > filed? It seems like it would provide all of the needed outgoing MTA > > functionality without requiring a daemon. > > Looking at the SSMTP bug page, the package seems to be very > unmaintained. :/ Two important bugs, one of which I'd consider critical, > both with patches, and no update for 6 months. That's too bad; it's a handy tool. I used it for a while at work until I converted everything to postfix (I wanted client queues). M pgpBAjxoCmmut.pgp Description: PGP signature
Re: Rotation of /var/log/mail.log
Steve Kemp said on Tue, Sep 23, 2003 at 10:45:11PM +0100: > > While /var/log/mail.log is rotated nicely on my (woody) boxes, > > I have no idea which package is responsible for that. > > Any suggestions ? > > /etc/cron.weekly/sysklogd > > This script rotates all the files which are output from running: > > /usr/sbin/syslogd-listfiles --weekly > > > That would help me to solve bug #212237. > > If you make sure there is an entry for mail in /etc/syslog.conf then > these files will be output from the 'syslogd-listfiles' and rotated > correctly. > Alternatively you could drop a file in /etc/logrotate.d/ to force > the issue. Please do this instead. I'm not sure why sysklogd does it's own rotation, but most other stuff uses logrotate, and it works well. M pgp597srBnu1y.pgp Description: PGP signature
Re: Rotation of /var/log/mail.log
Matt Zimmerman said on Tue, Sep 23, 2003 at 07:43:04PM -0400: > On Tue, Sep 23, 2003 at 02:59:02PM -0700, Mark Ferlatte wrote: > > > Please do this instead. I'm not sure why sysklogd does it's own > > rotation[...] > > Because sysklogd doesn't have a fixed set of log files. It does have a _default_ set of log files, which should be rotated by default. Apache doesn't have a fixed set of log files, either, but it uses logrotate just fine. As far as that goes, so does the syslog-ng syslogd replacement. It doesn't seem unreasonable to expect that if you change log file locations that you should/would have to change logrotation configuration, and having syslogd be seperate and special is just adding confusion without much gain. M pgp58Vz68q1vv.pgp Description: PGP signature
Re: Kernel weirdness
Cristian Ionescu-Idbohrn said on Fri, Oct 10, 2003 at 06:42:53PM +0200: > On Sun, 5 Oct 2003, Rob wrote: > > > I've installed the kernel-image-2.4.22-1-686 package. Until now, I've > > been running the 2.4.18-bf2.4 kernel. Though I didn't change what > > modules I load, with this new kernel package have come a whole bunch of > > new modules that are being loaded. I've run modconfig and removed them, > > but they continue to to load at boot. > > This insane behaviour is caused by initrd: The behavior is not insane. Prior to 2.4.20, the IDE driver was monolithic. As of 2.4.21, it got split into a bunch of chipset specific drivers. The kernel maintainer wisely decided to not change the existing functional behavior of the kernel, and so loads all of those drivers anyway since he doesn't know which of them you are using. If it really bothers you, make a new initrd.img with only the IDE driver that you need. M pgp0mVaYkOzWm.pgp Description: PGP signature
Re: Kernel weirdness
Cristian Ionescu-Idbohrn said on Fri, Oct 10, 2003 at 09:57:34PM +0200:
> With all due respect for the our kernel maintainer, Herbert Xu, throwing
> up all those ide-driver modules (on a scsi only box, or anywhere else) is
> IMHO insane :(
The IDE modules were there before, on your SCSI only box. They didn't hurt you
then, they don't now.
> At least provide some sort of hook one could use to cleanup that module
> jungle. Ideally, automatic detection of what is usable ('cat /proc/pci |
> grep -i ide' or lspci?) and removal of the useless junk, would be an
> elegant solution to this problem.
Well, if you really care, you can run this after boot:
modprobe -r $(lsmod | grep unused | cut -f1 -d' ')
M
pgpol5CmpvlTE.pgp
Description: PGP signature
Re: recent spam to this list
Manoj Srivastava said on Tue, Oct 14, 2003 at 04:40:15PM -0500: > Consider this use case: I travel a lot, and stay in hotels > with network connections. Unfortunately, these nigtly billed domains > have very poor mail gateways; I've been burned before. I now connect > directly and deliver mail from the MTA on my laptop. > > I do not know, a priori, what the IP address is likely to be, > and getting DNS changed for datasync.com would take days, not hours, > by which time I would no longer be at the IP. > > I do not have co-located servers; and my normal machine may > not be accessible from outside to tunnel to. Just like the postcards > I mail from the Hotel, the return address on my email points to a > valid mbox. > > Would there be any way to implement tihs use case with > everyone using SPF, and telling spamassassin to deep six failures? You've got an SMTP server somewhere that accepts mail, right? (Otherwise, how do you recieve?). Configure that server to relay for people who are using SMTP AUTH, and then configure your laptop to use that as a smart host using SMTP AUTH. Then, you SPF for your smart host only; no wacky Dynamic DNS hacks required. Frankly, that kind of setup works better anyway; you get your mail off of your non-reliably connected laptop ASAP, and then let your smarthost worry about queuing. M pgpFvWTY6V9xq.pgp Description: PGP signature
Re: faster boot
Robert Giardalas said on Sun, Oct 19, 2003 at 11:55:52PM -0400: > I had some preliminary modifications of the parallel loading system > proposed by James Hunt from IBM working for Debian, but it looked like > it would speed things up less than 10%, which wasn't enough to lure me > away from SysV, so I said it aside. I still have some of the files > around, if you want 'em. I don't subscribe to this list, though, so > email me directly. I suspect that the improvement would be _very_ system dependent, though. For example, netatalk takes a _long_ time to start, and parallelizing would be a benefit. sendmail can take a while too, especially if you have DNS issues at boot time. I have to admit though; I just think it's neat. :) M pgpJnAgp940eO.pgp Description: PGP signature
Re: Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO
Marc Haber said on Tue, Oct 21, 2003 at 05:57:03PM +0200: > On Wed, 15 Oct 2003 13:24:25 +0200, Andreas Metzler > <[EMAIL PROTECTED]> wrote: > >Being a normal Linuxdoc howto this has been available in Debian for a > >long time in doc-linux-html. > > And calling this document a HOWTO has been a joke since at least two > years. I don't consider myself entirely dumb, but I have failed to > understand the document. For a HOWTO, there are not enough examples, > and the few examples are so complicated that nobody can grasp the > concepts. Shrug. I found the LARTC to be very helpful. It is the Advanced Routing HOWTO, after all. M pgpiOS4t4er94.pgp Description: PGP signature
Re: [custom] Debian Enterprise - flavors
Zenaan Harkness said on Wed, Dec 03, 2003 at 02:58:18PM +1100: > Flavours (and sub-flavours/ tasks/ yadda) is as good a place to start as > any. So here are some proposed flavours: > > - Enterprise (base packages and more "neutral" config) > - Enterprise Desktop - with sub-flavours of: > - Secretary Desktop > - Presentation Client (OO Presenter, multimedia, flash) > - Developer Desktop (all build-depends of all flavours, as a start) > > - Enterprise Fileserver > - Enterprise Webserver > - Enterprise Auth Server > - Enterprise Departmental Server (combines File, Web + Auth) > > - Enterprise Firewall > - Enterprise SCM Server > - Enterprise Router > > - Enterprise Thin Client Something to keep in mind that most of the above could be handled by exactly the same software loadout. For example: There is no difference between Desktop, Fileserver, Webserver, Auth Server loadouts that matters; you just turn off the services by default and let the customization process turn on the services that matter for that role. It doesn't matter if the webserver has openoffice installed; it's just a few bits on disk. It might be worth reading http://www.infrastructures.org/papers/bootstrap/bootstrap.html before getting flavour happy. M pgpduCDZGTL4W.pgp Description: PGP signature
Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)
Tim Krieglstein said on Fri, Dec 05, 2003 at 02:10:57AM +0100: > I would like to have some feedback, especially on the topic of > doing automatic updates with an cron job. I would also like to hear of > some hints if there is an other tool which does the job (debix, > skolelinux,...: haven't looked at them. The websites of the subprojects seem > still to be hit by the security incedent :( ) better than these puny > script files. I think the whole automatic management thing (which is > also the reason behind the whole "enterprise" discussion) has a lot of > potential. Having the ability to reconfigure large clusters or > workstation installations is *really* helpful. I did what you are trying to do using systemimager, cvs, and cvsup. I use systemimager to install the initial Debian image (the golden-image, in systemimager terminology), that is created from a functional working Debian system (the golden-client). I also have a CVS repository off all per host configurations. A cron job runs the systemimager updateclient tool (basically an rsync wrapper) + cvsup once/hour. Using systemimager is nice because it's a file-based image; I don't have to worry about debconf, or installers; I just install the package once on the golden client, update the master image from the client, and then everything picks up the new software automatically. There are a few rough spots (mostly in that I don't have a fully automatic way to restart daemons that have been updated in the golden client, so I have to restart them by hand), but in general it works very well, and has saved me a lot of time. M pgpbLhnaVm7mJ.pgp Description: PGP signature
Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)
Chad Walstrom said on Fri, Dec 05, 2003 at 02:17:55AM -0600: > > I did what you are trying to do using systemimager, cvs, and cvsup. > > ... There are a few rough spots (mostly in that I don't have a fully > > automatic way to restart daemons that have been updated in the golden > > client, so I have to restart them by hand), but in general it works > > very well, and has saved me a lot of time. > > This is all very well and find if you're using a single architecture > with nearly identical hardware setups. Granted, with discover and > read-edid, things are a little easier. I am using all x86, but I've got very different hardware setups; 4 different types of RAID, many 1U boxen with different ethernet cards that are not RAID, some SMP some not, some SCSI, some IDE, etc. Pretty much all of the non-autodetectable hardware configuration is restricted to three places: the kernel, /etc/fstab, and lilo.conf/grub. (Okay, 4 places if you include the X server config). I have an SMP and a non-SMP kernel installed in the golden image, and I have a SCSI vs. non-SCSI initial setup (due to the different device filenames requiring different setup commandlines and fstab), but other than that, there's nothing special necessary. The machines that are SMP have lilo configured to start the SMP kernel instead of the UP one (since there's no autodetect for that at boot time), but that's not a big deal. The kernel's are just the Debian default ones, which have most things built as modules; I just load the disk driver modules that I know I need from the initrd (which means that I'm wasting a little kernel memory, but I could unload the unused ones after boot; I just don't). FAI is good, but it doesn't handle updating the systems once you have them installed. M pgpgvtr38XhjZ.pgp Description: PGP signature
Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)
Chad Walstrom said on Fri, Dec 05, 2003 at 10:05:15AM -0600: > On Fri, Dec 05, 2003 at 01:13:57AM -0800, Mark Ferlatte wrote: > > FAI is good, but it doesn't handle updating the systems once you have > > them installed. > > You're absolutely right. The cfengine scripts are also slightly > difficult to re-use after the initial installation. A good cfengine > setup is hard to beat for managing multiple boxes, but cvsup is > certainly a good way to do it. I like cfengine, but I haven't done anything in production with it yet. > It just goes to show that there is no One Right Way(tm) to do things. Indeed. But arguably there are better ways; it would be cool if Debian Enterprise would help support them. I've been spending a lot of time thinking about this sort of automatic machine maintanence; there's a lot of tools out there, but they all have weak spots here and there. There also doesn't seem to be many places where people are talking about this stuff, either; many seem to go out and roll their own system, which is fine, but then all the poor admins end up re-inventing the wheel, which is not fine. M, wheel re-inventor. pgpJsP4LKBH6w.pgp Description: PGP signature
Re: Dumb little utilities
begin Oohara Yuuma quote on Wed, Aug 28, 2002 at 11:57:31PM +0900: > > generate id3 tags from file name (probably not generally useful). > It may save some perl one-liner. id3ren does this. M pgp7m14E3fGi3.pgp Description: PGP signature
