Re: automated installation
In a message dated: Fri, 26 Jul 2002 20:06:25 EDT Michael O'Donnell said: I'm giving the FAI (Fully Automatic Installation) package a test drive at Paul's suggestion and wonder if anybody here has tried it. I'm hitting some speedbumps that (I think) have something to do with my attempts to use FAI's DHCP boot method with the DHCP server from the dhcpd3 package. Ayup, I've been playing with it for about 2 or 3 months now, on and off. The documentation, IMO, leaves a lot to be desired, but between that and the mailing list, you should be able to muddle through. Btw, in the case of FAI, the phrase Use the source comes into play more so than I realized at first. 99% of FAI's flexibility comes from shell and perl functions which are completely undocumented anywhere but in the source itself. Definitely take a look at the example class/*, scripts/*, and files/etc/* files. The DHCP config should be pretty straightforward, however, I can shoot you the one I'm using if you'd like. -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
I'm giving the FAI (Fully Automatic Installation) package a test drive at Paul's suggestion and wonder if anybody here has tried it. I'm hitting some speedbumps that (I think) have something to do with my attempts to use FAI's DHCP boot method with the DHCP server from the dhcpd3 package. Ayup, I've been playing with it for about 2 or 3 months now, on and off. The documentation, IMO, leaves a lot to be desired, but between that and the mailing list, you should be able to muddle through. Btw, in the case of FAI, the phrase Use the source comes into play more so than I realized at first. 99% of FAI's flexibility comes from shell and perl functions which are completely undocumented anywhere but in the source itself. Definitely take a look at the example class/*, scripts/*, and files/etc/* files. The DHCP config should be pretty straightforward, however, I can shoot you the one I'm using if you'd like. After struggling with FAI for a few days I noticed that a new Debian package had appeared so I started over with that and got a lot further. With the new package I've so far had problems related to TFTP, DHCP and SSH. I discovered (after some tortuous debugging) that the first two were the result of incompatibilities with the particular servers I was running, so in those cases I changed servers. The SSH problem turned out to be related to the recent privilege separation changes that have been pissing off a lot of people. By the end of the weekend I had gotten to the point where the client boxes could boot using a floppy and establish communications with the server box well enough that it looks like I'm now ready for the REALLY hard part: setting up classes and writing scripts that configure systems belonging to each of those classes. * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: Mon, 29 Jul 2002 11:23:55 EDT Michael O'Donnell said: I've so far had problems related to TFTP, DHCP and SSH. I discovered (after some tortuous debugging) that the first two were the result of incompatibilities with the particular servers I was running, so in those cases I changed servers. For DHCP, it's a lot easier to use the older DHCP v2.x series server. With the 3.x series server, they changed a bunch of the option-X options to be in the vendor defined options area instead. It's definitely do-able with the 3.x series server, but a little more futzing is required to get it to work. For tftp, it's definitely best to use the hpa-tftp server from H. Peter Anvin as recommended in the docs. The SSH problem turned out to be related to the recent privilege separation changes that have been pissing off a lot of people. I got bit myself by this on Friday as I was trying to build a new bldsvr machine to go into production rather than my sandbox system I've been experimenting with. It pissed me off, and I'm not even sure what I did to get around the problem, but it's working now. By the end of the weekend I had gotten to the point where the client boxes could boot using a floppy I haven't had the chance to deal with the boot floppy at all, having to good fortune to be in possession of spare machines which all have PXE capability. looks like I'm now ready for the REALLY hard part: setting up classes and writing scripts that configure systems belonging to each of those classes. This is actually really easy, as it's nothing more than writing class/* shell scripts which write a class name to STDOUT in order to define a class based upon whatever criteria you choose. The scripts/* can be shell, perl, or cfengine scripts. Actually, I think the class/* scripts can be perl, shell, or cfengine as well. -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. Have you appreciated your SysAdmin today? http://www.sysadminday.com/ If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
[EMAIL PROTECTED] writes: Putting it under /usr doesn't really make sense -- /usr is where static files live, not user data. This does seem to be a best practice nowadays. However, there used to be a time when user directories used to be placed under /usr. Then things changed, and everybody started using other directories, most notably, /home . What were the reasons for this change? I can see a couple of reasons, most notably: o using /home can help facilitate a NFS/automounter (etc.) environment. (a lot of sites have /home mapped to a central server) o splitting users directories off from /usr (where other system things are held) can be useful when it comes time for doing backups or an OS install/upgrade/recovery. I guess, in short, it's a bit of convenience to have users directories all grouped together. But are there any other reasons that I'm overlooking? --kevin -- Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA) cetaceannetworks.com!kclark (GnuPG ID: B280F24E) alumni.unh.edu!kdc * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Thu, 25 Jul 2002 [EMAIL PROTECTED] wrote: But that leaves us with no place to put htdocs. Putting it under /usr doesn't really make sense -- /usr is where static files live, not user data. /usr/local/htdocs might make sense, but Red Hat wanted to leave /usr/local for things not packaged by Red Hat. Ditto /opt. They ended up choosing /home because it was the web server's home, so to speak. I think /var/svc/httpd or something would have been a better choice, but as you say, sometimes it is just a matter of taste. Interesting. Mandrake puts Apache's default root in /var/www/html, and I have it symlinked on one system to /home/apache, to make it easier to backup/preserve-across-update the files, so I gather that I've come around to Red Hat's way of thinking without realizing it ... :) -- Bill Mullen 1:58pm, 2002-07-26 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: Fri, 26 Jul 2002 15:03:26 EDT [EMAIL PROTECTED] said: Another, similar debate is whether /usr/local should be for site-local or machine-local files. We've had that here before, too. I've actually flip-flopped my opinion of this one :) I used to advocate that /usr/local should mean local to a site not a machine. My opinion now is that /usr/local should be defined to mean whatever the site's sysadmin thinks it should be :) That way, if the site admin believes it should be for site specific stuff, (s)he can make that call. If (s)he believes it's for machine specific stuff, then so be it :) About the only standard I can be sure of here is that when there is no standard, long debates about semantics usually ensue. :) Well, Duh! ;) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. Have you appreciated your SysAdmin today? http://www.sysadminday.com/ If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On 26 Jul 2002, at 2:53pm, Kevin D. Clark wrote: However, there used to be a time when user directories used to be placed under /usr. Right. From what I understand, the embryonic Unix systems were single-user machines, with a very few top level directories: /src for source, /bin for binaries, /etc for all that system stuff, /dev for devices, and /tmp for temporary files (did I forget any?). When multi-user functions were added, the /usr directory was created for user files. When additional disks were added, /usr was also used as the mount-point. (I'm not sure which came first.) Because the /usr disk had more space than / disk, all the former to-level directories were re-created and stuff dumped there, leading to a bit of mess. It isn't that bad to have a one or two /usr/bscott directories, but on a large, multi-user system, it gets kind of ugly. Then things changed, and everybody started using other directories, most notably, /home . /sbin, /opt, and /var are other notable additions. I guess, in short, it's a bit of convenience to have users directories all grouped together. But are there any other reasons that I'm overlooking? /usr can be network-mounted and/or read-only with user directories under /home. The LSB says distributors *must* allow /usr to be mounted read-only. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Thu, 25 Jul 2002, Ben == [EMAIL PROTECTED] wrote: Ben Anyone used to any other Unix will Ben find Linux a bit weird in this respect. Let's re-write this as: Anyone used to any one particular OS will find another particular OS a bit wierd in this respect. I think it's safe to say, that though UNIX is UNIX, and Linux is UNIX, that if you *really* know one variant, trying to switch to another, though not hard, does turn up some idiosyncrosies which can lead to confusion and/or frustration. (The following are meant to be rhetorical questions, however, they may prove interesting excercises for some :) For example, anyone know what /etc/fstab is under: - AIX - Solaris or what /etc/exports is under: - Solaris How about trying to change the hostname of a system between: - Solaris - Linux (actually, RH, Debian, etc, are all different) - True64 - HP-UX - AIX For that matter, how do you change the networking interface information between: - Red Hat - Debian Tux forbid you're an NT admin trying to learn The UNIX way :) -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: Fri, 26 Jul 2002 12:08:02 EDT Rich Payne said: On Fri, 26 Jul 2002 [EMAIL PROTECTED] wrote: In a message dated: Fri, 26 Jul 2002 11:20:58 EDT [EMAIL PROTECTED] said: On Fri, 26 Jul 2002, at 11:08am, [EMAIL PROTECTED] wrote: or what /etc/exports is under: - Solaris Oh, oh, teacher, I know this one! /etc/dfstab! (Am I right? It's been awhile... :) Nope! /etc/defaults/dfstab :) it's /etc/dfs/dfstab on my 5.7 and 5.8 boxes. /etc/defaults/ doesn't even exist. Oh, right, sorry. It's been over 2 years since I've touched Solaris. Guess I'm as rusty as Ben is on this one. Of course, we both knew the file was dfstab, so we could do a 'locate dfstab' and find it, right ;) (that was sarcastic, I know, I need to use 'find /etc -name dfstab' if I really want to find it :) As for not calling it /etc/exports, well dfstab doesn't really contain exports like we think of on Linux. It contains share commands that get run on startup to share the filesystems. I think not calling it /etc/exports was actually right in this case (wait, am I actually defending Sun/Solarisyikes, must be time for a holiday) I'd say so :) And once again, you've pointed out another area where I was confused (there are oh, so many :) It's /etc/vfstab that has the 2 extra fields, not dfstab. The dfstab, as you mentioned, has the 'share' commands, making dfstab more of a shell script than an exports file. Another thing I don't quite get the logic of. /etc/exports and exportfs always worked just fine for me under every other version of UNIX. -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
I'm giving the FAI (Fully Automatic Installation) package a test drive at Paul's suggestion and wonder if anybody here has tried it. I'm hitting some speedbumps that (I think) have something to do with my attempts to use FAI's DHCP boot method with the DHCP server from the dhcpd3 package. * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
[EMAIL PROTECTED] said: On 26 Jul 2002, at 2:53pm, Kevin D. Clark wrote: However, there used to be a time when user directories used to be placed under /usr. Right. From what I understand, the embryonic Unix systems were single-user machines, with a very few top level directories: /src for source, /bin for binaries, /etc for all that system stuff, /dev for No, the 1st Unix systems on PDP-11s (Bell Systems Labs Journal volume *mumble*) were multi user. They had 2 disks, one fast small and one larger and slower. The slower disk was /usr and less frequently used items went there. The faster disk was the home of / bin. So the frequently used programs like ed, sed, grep, test, echo, etc.. went there. Because of the nature of the system, I think user data also went into / usr as well. They were developing the system and supporting Bell Lab's patent application writers on the same system. And they were developing things like grep, awk, pcc, and nroff at the time. Then things changed, and everybody started using other directories, most notably, /home . OS upgrades usually mangled stuff in /usr. So people started putting local site stuff out of /usr and even created /usr/local. Many 3rd party vendors continued to put stuff in /usr. I remember installing stuff as late as '94 that did this. /sbin, /opt, and /var are other notable additions. There were some applications in /etc (ping even?). /sbin and /usr/sbin were created to pull them out. SunOS didn't have sbin for example and many sysadmin apps were in /etc. Back in the old days, vendors put stuff in /usr (this is before pkgadd, rpm, etc). People started creating a /usr/local. Solaris came out with the idea of /opt for 3rd party stuff. I am a bit Sun centric here, but I have worked with Irix 4.x/ 5.3, HP-UX 9.x-11 and ultrix in the past too. I was writing scripts that would get disk geometry, partitioning, mounts and usage from each system. Beleive me, every OS has a different program in a different location to deal with disks. I think the GNU suite of tools ./config went a long ways toward getting stuff out of /usr and into /usr/local and other areas. Before ./config, installing a new package was a bear. Dig up an old package of PBMplus, MH, or Columbia Appletalk ( 150 patches to install). Even ghostscript was a pain until recently. -- --- Tom Buskey * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: Thu, 25 Jul 2002 10:25:26 EDT Derek D. Martin said: However in Red Hat's defense, one thing to realize is that the number of software components included with a distribution like Red Hat makes it impossible to QA everything thoroughly. Which is also one of the reasons it takes Debian 2.5 years to issue a new release! The number of packages shipped with Linux distributions these days is simply astounding, bordering on ridiculous. I haven't touched anything but Linux for over 2 years now, and I'm quite sure I'd feel lost elsewhere with commercial system's sparsity of packages! Regardless of distribution, you get a lot more bang for your buck with Linux than you do with any commercial OS! Now, if we could just boost the QA level of all the distributions a little :) -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Thu, 25 Jul 2002 [EMAIL PROTECTED] wrote: Which is also one of the reasons it takes Debian 2.5 years to issue a new release! Oh, come, come -- it's not really -that- quick, is it? ;-) Regardless of distribution, you get a lot more bang for your buck with Linux than you do with any commercial OS! Now, if we could just boost the QA level of all the distributions a little :) Alas, QA has one (or two, depending on how you look at it) strike(s) against it: - it's not sexy, which means relatively few do it voluntarily, which means - it costs money. That being said, more testing is required... but even less likely to happen, what with, as Paul noted, the almost ridiculous amount of software one gets with a stock distribution these days. Fer Pete's sake: my first slackware base install was something like 8 floppies (plus boot root). I imagine Mandrake will hit that number of CD-ROMs soon, if they haven't already! Funny -- that roughly follows Moore's Law. I wonder if there's a correlation? [Ken in 2010: Sheesh! Where'd I put DVD #17?] -Ken * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: Thu, 25 Jul 2002 08:44:59 PDT Ken Ambrose said: On Thu, 25 Jul 2002 [EMAIL PROTECTED] wrote: Which is also one of the reasons it takes Debian 2.5 years to issue a new release! Oh, come, come -- it's not really -that- quick, is it? ;-) This most recent one was only 2.5 years. I believe slink-potatoe took 3 years :) Alas, QA has one (or two, depending on how you look at it) strike(s) against it: - it's not sexy, which means relatively few do it voluntarily, which means - it costs money. I'm actually suprised more people don't want to do QA. I mean, it's rare that you can actually get paid for breaking things. The real bonus is that once you break them, you don't have to fix them, you get to pass that ball to someone else in development :) Fer Pete's sake: my first slackware base install was something like 8 floppies (plus boot root). I remember my first Slackware install. 3.0, about 8 floppies, unless you wanted Emacs, then it was 25 :) I imagine Mandrake will hit that number of CD-ROMs soon, if they haven't already! Funny -- that roughly follows Moore's Law. I wonder if there's a correlation? [Ken in 2010: Sheesh! Where'd I put DVD #17?] I believe the latest Debian release *is* 7 or 8 CDs at this point! Personally, I beginning to think it's far easier to just install a base OS (similar to what you get with commercial UNIXes), then do something like apt-get or rpm-up2date to install new, non-OS stuff. -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Thu, 2002-07-25 at 13:54, [EMAIL PROTECTED] wrote: I believe the latest Debian release *is* 7 or 8 CDs at this point! The latest Debian release, Potato r3.0, is 8 CD's. I was going to make ISO's using Jigdo over the weekend until I relaized this. I didn't have enough drive space to assemble all 8 ISO's, so I'm doing them one a day. Personally, I beginning to think it's far easier to just install a base OS (similar to what you get with commercial UNIXes), then do something like apt-get or rpm-up2date to install new, non-OS stuff. This is what I have been doing for quite some time. I have one Debian CD that I use to do a bare minimum install. Then I have an options file on a floppy that I created using `dpkg --get-selections`. When the selections are loaded on the new system (using dpkg --put-selections), I do an apt-get and go home for the night ;-) I haven't used RH since 6.2, so I don't know if there is a way to do the same automation with rpm. Is rpm-get functional yet? C-Ya, Kenny -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
Kenneth E. Lussier said: On Thu, 2002-07-25 at 13:54, [EMAIL PROTECTED] wrote: Personally, I beginning to think it's far easier to just install a base OS (similar to what you get with commercial UNIXes), then do something like apt-get or rpm-up2date to install new, non-OS stuff. This is what I have been doing for quite some time. I have one Debian CD that I use to do a bare minimum install. Then I have an options file on a floppy that I created using `dpkg --get-selections`. When the selections are loaded on the new system (using dpkg --put-selections), I do an apt-get and go home for the night ;-) I haven't used RH since 6.2, so I don't know if there is a way to do the same automation with rpm. Is Of course. Mandrake has rpmdrake / MandrakeUpdate. You can tell it to look at a mirror instead of CDs. And there's Ximian's red-carpet. I find it's better then rpmdrake. Of course, I don't want the Ximian desktop on my servers. rpm-get functional yet? -- --- Tom Buskey * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Thu, Jul 25, 2002 at 01:54:58PM -0400, [EMAIL PROTECTED] wrote: In a message dated: Thu, 25 Jul 2002 08:44:59 PDT Ken Ambrose said: Alas, QA has one (or two, depending on how you look at it) strike(s) against it: - it's not sexy, which means relatively few do it voluntarily, which means - it costs money. I'm actually suprised more people don't want to do QA. I mean, it's rare that you can actually get paid for breaking things. The real bonus is that once you break them, you don't have to fix them, you get to pass that ball to someone else in development :) The problem there is a number of factors: 1) Developers don't want FAQs, and generally take a dim view of end users (see mplayer). 2) Users assume the bug has already been reported. 3) End users usually don't know how to generate good bug reports. It doesn't work never cuts it. Any bug you report has to be repeatable by the developers. -Mark * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: 25 Jul 2002 14:23:47 EDT Kenneth E. Lussier said: This is what I have been doing for quite some time. I have one Debian CD that I use to do a bare minimum install. Then I have an options file on a floppy that I created using `dpkg --get-selections`. When the selections are loaded on the new system (using dpkg --put-selections), I do an apt-get and go home for the night ;-) I've begun playing with FAI and PXE boot systems. I have a local debian mirror which is also set up as an FAI server. My clients use PXE to boot (though you can accomplish the same with a boot floppy) and the system is built and booted within about 10 minutes, completely customised for my environment, based on the specific either the hardware configuration of the client itself or it's destined role in life. Much better than a manual install via CD or even FTP/NFS installs. -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: 25 Jul 2002 14:54:32 EDT Kenneth E. Lussier said: I have three different selections floppies. One for desktop systems, one for laptops, and one for servers. Once the base is installed and everything gets installed from the selections floppy/apt-get, I manually install the system-specific pakages, usually from source. You could replace all the floppies with a single boot floppy and let FAI determine what gets installed on what system based on what class the booting client falls into :) -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, Paul Iadonisi hath spake thusly: Compare Derek's complaints to what I would consider standard sysadmin practices as espoused by Evi Nemeth, et al, in the UNIX/Linux System Administrator's Handbook series. RH violates these basic practices with their configurations many times. *sigh* I see the horse *is* still twitching. At first glance, and knowing Red Hat's distribution quite well, I'd have to disagree. However, I will now go read Derek's supposedly entertaining bug reports for a more accurate understanding of what you are saying. Well, I wish you wouldn't. Ben is right in that some of those bug reports are less than complementary. On a few occasions, I've allowed frustration to get the better of me, and said some things I'd probably prefer I didn't... Paul L. is right though, I've been submitting bug reports for every distribution (barring .0 releases, which I wouldn't run on anything critical) since RH 5.1, and there have been some pretty amazing cases... Some of the better ones I've submitted were under a variety of different e-mail addresses, which I'm not going to bother to list. I've also added extensive comments to bug reports submitted by other people, which also wouldn't show up in Paul's query. I do agree with Paul that Red Hat does need better QA. My personal favorite bug was where Red Hat broke /bin/sort by adding i18n support to it. GNU textutils comes with a test suite, which RH's engineers quite obviously never ran... The best part is it took them over 6 months to release a fix... But they have had a number of other bugs that I've encountered that, had anyone tried to set up a particular very common case, could not possibly have gone unnoticed. However in Red Hat's defense, one thing to realize is that the number of software components included with a distribution like Red Hat makes it impossible to QA everything thoroughly. But I do still feel they could use some guidance in chosing what subsystems probably need more rigorous testing, and what common cases exist that sysadmins are likely to break... Beyond QA, I also think they do some really bizzare things with the way they organize and configure certain things (like putting the web server's document root in /home) that would make a lot of experienced Unix system administrators cringe. This is more a matter of taste and style than QA, but I think they could use some work there too. Thankfully, they're trying to adhere to the LSB, which eliminates a lot of those problems, or at the very least documents them. - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9QApWdjdlQoHP510RAiwKAJ9Z7MvHlVFGNoSz1oo/WHuPgMedOQCdFjgZ PHrcL6fuOEQ93eRZb29bi1A= =ua9J -END PGP SIGNATURE- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, [EMAIL PROTECTED] hath spake thusly: On Wed, 24 Jul 2002, at 10:55am, [EMAIL PROTECTED] wrote: I don't disagree with any of that, I was merely stating that it's an amusing read. You forget there is a real person on the other end of it. I have been the object of that kind of abuse too many times to find it amusing. :-( All I can say in my defense is, frustration + liquor != happy bug reporting... I actually do agree with you. ... espoused by Evi Nemeth, et al, in the UNIX/Linux System Administrator's Handbook series. RH violates these basic practices with their configurations many times. Heh. My take on the same thing was that USAH didn't get many things about Linux and GNU. :-) The biggest being: GNU's Not Unix. When you say this, it makes me think that you don't get GNU. GNU's *not* Unix. But it was always intended to work like Unix, by and large. While it's true that: There are times where Red Hat (and others) have decided not to perpetuate certain braindamages from traditional Unix. That doesn't mean that they haven't introduced their own brain damage, which can sometimes be as bad or worse than the commercial Unixen. A good example is the whole /var/spool/mail thing. Historical Unix made that directory world writable with the sticky bit set. The major reason for that was locking -- programs created lock files in that directory to reserve write access to a mailbox. Of course, it is also a rather big security exposure, especially on a large, multi-user system. It doesn't have to be, and it shouldn't be. I was (initially) not aware that Linux allowed arbitrary users to create hard links to any other arbitrary user's files, despite any ownership and permissions on the original file. This is the worst of the problem. I brought this issue up on LKML, and finally AC made the concession that there should at least be a mount option to prevent that behavior. Allowing it is, in most cases, just plain stupid. This is a case where the Linux developers did NOT erase a brain damage, in the name of making it work like traditional Unixen. It was pointed out that neither POSIX nor SUS require this behavior, and that seemed to sway some opinions... Beyond that though, the security implications are fairly minor. Proper implementation and enforcement of policy, and attention to permissions on created files will mitigate or eliminate most of them. Red Hat went to the trouble of making sure all the mail programs on their system use kernel-level locking (flock/fcntl), eliminating the need for that long-standing braindamage. And I say: Good! Sort of... Traditionally, the only method of locking guaranteed to work across Unix systems was to create a unique file, then link(2) the well-known lock file to it. If the link() succeeds, you have your lock. If it doesn't, try, try again. Kernel level locking especially does not work particularly well with NFS on many platforms, but ironically it's the ONLY method that works reliably with NFS on Linux. So if you need to interoperate via NFS with multiple platforms (something that is done in many environments), you're pretty much guaranteed that your locking mechanism will break somewhere, no matter what you pick... You can compensate by choosing to use multiple methods, but then you have a race condition... OTOH, it's also my opinion that you should *never* make your mail spool available via NFS. Ok, maybe not never, but I can't imagine wanting to work in an environment where doing so can be argued to make sense. Between the locking issues and the security implications, it's just a bad, bad idea. - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9QHOTdjdlQoHP510RAgEWAJ9cI4vIaCilOj7VWDof7NPrICroUgCginKX gEcpgi+O90eY+hpw5BcDkmc= =4e0V -END PGP SIGNATURE- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Thu, 25 Jul 2002, at 5:54pm, Derek D. Martin wrote: When you say this, it makes me think that you don't get GNU. GNU's *not* Unix. But it was always intended to work like Unix, by and large. I have written and rewritten a response to this several times now. In all cases, the inevitable conclusion is an argument over semantics, and/or the fact that USAH is a holy cow for you. I don't want to go there. :-) That doesn't mean that [Linux distributors] haven't introduced their own brain damage ... Oh, gawd, have they ever. I was never trying to say they were perfect. Indeed, in many cases, they have taken one or two steps back for every step they have taken forward. :-( A good example is the whole /var/spool/mail thing. Historical Unix made that directory world writable with the sticky bit set. The major reason for that was locking -- programs created lock files in that directory to reserve write access to a mailbox. Of course, it is also a rather big security exposure, especially on a large, multi-user system. It doesn't have to be, and it shouldn't be. I am sorry, but I am confused on your context here. In that sentence, does it evaluate to the mail directory or a world-writable directory? This is a case where the Linux developers did NOT erase a brain damage, in the name of making it work like traditional Unixen. Alas, the let's fix it now while we have the chance mentality does not always win. Sometimes for good reason, sometimes for not-so-good reasons. Your example, I think, is one of the not-so-good instances. I have noticed that Alan Cox and some of the other kernel hackers occasionally retreat into the Unix has always done things this way defense when a more objective approach might be called for. The whole devfs debate comes to mind Proper implementation and enforcement of policy, and attention to permissions on created files will mitigate or eliminate most of them. Did you get that from Microsoft's playbook? :-) Yah, we know this is a really bad idea, but if you do this, this, and this, you can smooth most of the wrinkles out... No, thank you. :) Red Hat went to the trouble of making sure all the mail programs on their system use kernel-level locking (flock/fcntl), eliminating the need for that long-standing braindamage. And I say: Good! Sort of... Traditionally ... There's that word again. Traditionally. Here is a story I like to tell: A daughter is watching her mother make dinner -- a roast. She notices that her mother cuts the end off the roast and throws it away before putting the roast in the oven. She asks her mother why. Her mother says, Well... um... I think it makes the juices come out and adds flavor.. but I'm not really sure. My friend Mary taught me to cook, and that's the way she always did it. So the daughter calls her mom's friend, and asks her why she cuts the end of the roast off. Mary says, You know, I never really thought about it. That's just the way my mom taught me to do it. So, now being really curious, the daughter asks for Mary's mother's phone number, and calls her. She asks, Mrs. Smith, why do you cut the end of the roast off before putting it in the oven? And Mrs. Smith says, So it will fit in the pan. That fact that Unix has traditionally had poor file locking support is a reason to fix things -- not to continue using poor locking! So if you need to interoperate via NFS with multiple platforms ... you're pretty much guaranteed that your locking mechanism will break somewhere, no matter what you pick... Right. What I don't understand is why that is used as an argument in favor of using files as lock semaphores for mail. As you've already said, NFS locking is notoriously wonky in a heterogeneous environment, so what Red Hat does doesn't really make things any worse than they already were. And it does improve things markedly within Red Hat's domain. I think they did the Right Thing. But again, this is turning into an argument over design decisions. Sometimes there is more than one way to do things, and the right one is more a matter of taste than anything else. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Thu, 25 Jul 2002, at 10:25am, Derek D. Martin wrote: On a few occasions, I've allowed frustration to get the better of me, and said some things I'd probably prefer I didn't... Well, Derek, if it makes you feel any better, I think that happens to everyone now and again (certainly, to me!), and I commend you for admitting it. Beyond QA, I also think they do some really bizzare things with the way they organize and configure certain things (like putting the web server's document root in /home) that would make a lot of experienced Unix system administrators cringe. Ah yes. That. This is another of those Linux is different cases that I was talking about. Outside of Linux, there is always a base system that comes from one vendor or organization. Even the BSDs have a base system plus the ports section. Third-party software (like Apache) is generally installed under /usr/local (or /opt). When you have /usr/local/apache/bin, lib, conf, log and so on, it only makes sense to put the Apache web root there, too. But with Linux, it is *all* third-party software. If Red Hat (or anyone else) did what all the other Unixes do, there would be hundreds -- if not thousands -- of package directories under /usr/local, and *nothing* in /usr at all. That is obviously the Wrong Thing. So, they put Apache binaries in /usr/bin, and modules in /usr/lib/apache, and configuration in /etc/httpd/. Which, to me, makes sense. With Linux, everything that was formerly third-party gets moved up, so to speak. But that leaves us with no place to put htdocs. Putting it under /usr doesn't really make sense -- /usr is where static files live, not user data. /usr/local/htdocs might make sense, but Red Hat wanted to leave /usr/local for things not packaged by Red Hat. Ditto /opt. They ended up choosing /home because it was the web server's home, so to speak. I think /var/svc/httpd or something would have been a better choice, but as you say, sometimes it is just a matter of taste. I realize you yourself must know this, but I wanted to explicitly detail it anyway. For one, others might not realize it. But more-so because I wanted to highlight *why* Linux doesn't behave the way traditional Unix does. Anyone used to any other Unix will find Linux a bit weird in this respect. ... [the LSB] at the very least documents them. One of my biggest beefs with Red Hat is the lack of general system documentation. Likewise, one of the things that impresses me the most about Debian is the Policy manual. Per-program manual pages and user guides are certainly needed, but an overall system has to have a plan, too, and I wish Red Hat documented their plan better. (I'm giving them the benefit of the doubt by assuming they have a plan. ;-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: Tue, 23 Jul 2002 16:09:11 EDT [EMAIL PROTECTED] said: The early iterations of Red Hat's anaconda install did have some serious bugs in them. Let's re-write that as: The iterations of Red Hat have some serious bugs in them. It's more efficient and more accurate :) It usually takes Red Hat two or three tries to get something right, but they usually do get it right, eventually. ;-) I'd say they usually, after 2 or 3 tries get it *mostly* right. I have yet to see them release anything that didn't have at least one major problem which resulted in Derek bitching quite vocally to me about it. Or vice versa for that matter :) For an amusing chuckle, check out RH's bug reports searching on Derek as the submitter. He has a way with words :) https://bugzilla.redhat.com/bugzilla/buglist.cgi?email1=ddm%40emailreporter1=1email2=changedin=chfieldfrom=chfieldto=Nowchfieldvalue=short_desc=long_desc=bug_file_loc=status_whiteboard=cmdtype=doitorder=Bug+Number+Ascendingform_name=query After looking at this list of bugs, it appears I was mistaken, he's only reported bugs on versions 6.2, 7.1, and 7.2. I assume he considered it a waste of time to bother reporting bugs on 7.0 :) -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Wed, Jul 24, 2002 at 09:58:35AM -0400, [EMAIL PROTECTED] wrote: In a message dated: Tue, 23 Jul 2002 16:09:11 EDT [EMAIL PROTECTED] said: The early iterations of Red Hat's anaconda install did have some serious bugs in them. Let's re-write that as: The iterations of Red Hat have some serious bugs in them. It's more efficient and more accurate :) Now now It usually takes Red Hat two or three tries to get something right, but they usually do get it right, eventually. ;-) I'd say they usually, after 2 or 3 tries get it *mostly* right. I have yet to see them release anything that didn't have at least one major problem which resulted in Derek bitching quite vocally to me about it. Or vice versa for that matter :) For an amusing chuckle, check out RH's bug reports searching on Derek as the submitter. He has a way with words :) I could counter with the bugs I've submitted to Debian for resolving and how well those went (not to mention the number of e-mails/IRC chats with Wichert trying to figure out WTF broke while installing soemthing), but I'm above that. ;) Distros have their problems, no doubt about it. It's fortunate we can have this discussion at all as compared to Windows users. It's also fortunate that we can find our own ways around some of the problems that also happen to be distro-agnostic (SI instead of kickstart for example). -Mark * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Wed, 24 Jul 2002, at 10:26am, Mark Komarinski wrote: Distros have their problems, no doubt about it. It's fortunate we can have this discussion at all as compared to Windows users. It's also fortunate that we can find our own ways around some of the problems that also happen to be distro-agnostic (SI instead of kickstart for example). Well said! -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: Wed, 24 Jul 2002 10:33:00 EDT [EMAIL PROTECTED] said: I have seen Derek's Red Hat bug reports before. He is often rude, abusive, and/or insulting, none of which are productive. You might find that sort of thing funny, but frankly, I think he does himself, Red Hat, and the community a disservice by acting that way. It is one thing to bitch and moan on a independent mailing list (like this one) or around the local bar. It is quite another to act that way in what is intended to be a bug reporting tool. I don't disagree with any of that, I was merely stating that it's an amusing read. Also, of the six bugs turned up by that URL you posted, four are either user error, local configuration, and/or Just because Red Hat does not do things the way Derek Martin expects does not mean it is a bug. (The other two are quite legitimate, long-standing problems. Red Hat is *far* from perfect.) Which ones are you referring to? In the RH does not do things the way Derek expects them to be category, I'd re-word that as RH does not do things the way most sysadmins expect things to be. Most of those gripes are a matter of RH not having experience sysadmins doing QA for them. Compare Derek's complaints to what I would consider standard sysadmin practices as espoused by Evi Nemeth, et al, in the UNIX/Linux System Administrator's Handbook series. RH violates these basic practices with their configurations many times. -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
In a message dated: 24 Jul 2002 10:49:57 EDT Kenneth E. Lussier said: Do we really need to re-hash this *AGAIN*??? But the horse is still twitching! It's not quite dead yet! ;) -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
Do we really need to re-hash this *AGAIN*??? But the horse is still twitching! It's not quite dead yet! ;) You're such losers - anybody can see that the vi-versus-emacs flamewar is by FAR superior to the Linux-distro one... (Heh. I was just wondering if it's possible for me to start a meta-flamewar... ;-) * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Wed, 2002-07-24 at 11:06, Michael O'Donnell wrote: You're such losers - anybody can see that the vi-versus-emacs flamewar is by FAR superior to the Linux-distro one... I'm not a big fan of the 5 editor. And eMacs, well, isn't that Apple's version of a networked toilet-seat looking laptop?? ;-) C-Ya, Kenny -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Wed, Jul 24, 2002 at 11:19:13AM -0400, Kenneth E. Lussier [EMAIL PROTECTED] wrote: On Wed, 2002-07-24 at 11:06, Michael O'Donnell wrote: You're such losers - anybody can see that the vi-versus-emacs flamewar is by FAR superior to the Linux-distro one... I'm not a big fan of the 5 editor. And eMacs, well, isn't that Apple's version of a networked toilet-seat looking laptop?? ;-) Actually, vi would be 6 (so says me, Robert John Bell IV). Now vim, OTOH, well, I'm not sure that's legitimate Roman numerals, but if I had to treat it as such, I suppose I'd call it 994 (that's 0x3E2, 01742, or 100010 for those of you who have been behind a keyboard too long). And yes, there really was no point to this email... -- Bob BellHewlett-Packard Company Software Engineer 110 Spit Brook Rd - ZKO3-3/U14 TruCluster GroupNashua, NH 03062-2698 [EMAIL PROTECTED] 603-884-0595 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Wednesday, July 24, 2002, at 10:49 AM, Kenneth E. Lussier wrote: OK, before the My distro is better than yours starts again, I can save everyone the trouble: A bunch of people like Debian because it's more stable, apt-get is better than RPM, and it's very hands-on. A bunch of people like Red Hat because RPM is better than apt-get, and it's easier to install, and has simple management. A bunch of people like SuSE because it comes with everything under the sun, and has a good install and management system. A bunch of people like Mandrake because it's more desktop-friendly. Do we really need to re-hash this *AGAIN*??? Don't forget Slack!! There are still some people who like Slackware because Linux is fun. Erik * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Wed, 2002-07-24 at 10:55, [EMAIL PROTECTED] wrote: [snip] Most of those gripes are a matter of RH not having experience sysadmins doing QA for them. Um, EXCUSE ME, but I'm an experienced sysadmin and *I* do QA for them. I'm on the beta team. And I know *many* who do testing who are quite experienced sysadmins as well. However, I concede, that I can't test everything. Compare Derek's complaints to what I would consider standard sysadmin practices as espoused by Evi Nemeth, et al, in the UNIX/Linux System Administrator's Handbook series. RH violates these basic practices with their configurations many times. *sigh* I see the horse *is* still twitching. At first glance, and knowing Red Hat's distribution quite well, I'd have to disagree. However, I will now go read Derek's supposedly entertaining bug reports for a more accurate understanding of what you are saying. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
Michael, I'm not sure what your software is/or does, so this comment might be totally off the wall, but have you considered using the web to 'distribute' your application? If you are building software that accesses a centralized store of information and it can be done within the relatively simple confines of a browser based interface, then you don't really have to worry about distributing your application at all. Changes can be done on the server side and all clients (browsers) connecting in immediately see all new changes... Of course if you are building the new Photoshop or something then this makes no sense. :) Rich Michael O'Donnell wrote: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. For example, one scheme I've heard of (but have been unable to find at scyld.com or anywhere else) was reportedly developed by the Scyld Beowolf folks and it sounded very interesting - you could supposedly insert a Scyld CD into each one of a bunch of machines on your net, boot each machine from its CD, designate one machine as Master, and they'd all then cooperatively initialize themselves, install the software onto their local disks and start cranking as a Beowolf cluster. Although I'm not working with Beowolf I am involved with clustered systems so such a scheme sounds like it might be of interest - can anybody supply any details, or recommend any other approach to automated, net-based, multi-system installation? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * begin:vcard n:;Richard x-mozilla-html:FALSE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Richard Soule end:vcard
Re: automated installation
On Wed, 24 Jul 2002, at 10:55am, [EMAIL PROTECTED] wrote: I don't disagree with any of that, I was merely stating that it's an amusing read. You forget there is a real person on the other end of it. I have been the object of that kind of abuse too many times to find it amusing. :-( Which ones are you referring to? In the RH does not do things the way Derek expects them to be category, I'd re-word that as RH does not do things the way most sysadmins expect things to be. I would answer that question, but I suspect the discussion would quickly turn into a pointless argument over design decisions. Do we really need to re-invent the whole BSD-vs-SysV war with new players? ... espoused by Evi Nemeth, et al, in the UNIX/Linux System Administrator's Handbook series. RH violates these basic practices with their configurations many times. Heh. My take on the same thing was that USAH didn't get many things about Linux and GNU. :-) The biggest being: GNU's Not Unix. There are times where Red Hat (and others) have decided not to perpetuate certain braindamages from traditional Unix. I, for one, am thankful for that in many cases. Yes, it sometimes causes older software to break. The answer is to fix the software. A good example is the whole /var/spool/mail thing. Historical Unix made that directory world writable with the sticky bit set. The major reason for that was locking -- programs created lock files in that directory to reserve write access to a mailbox. Of course, it is also a rather big security exposure, especially on a large, multi-user system. Red Hat went to the trouble of making sure all the mail programs on their system use kernel-level locking (flock/fcntl), eliminating the need for that long-standing braindamage. And I say: Good! Just because Unix has been stupid about this for twenty years does not mean we should continue to be stupid about it. World writable directories are bad idea, and many (myself included) consider Unix's dependence on them a design flaw. Sorry if that rains on your parade, but as the Perl folks say, TIMTOWTDI. Nobody is forcing you to use Red Hat. I am sure there is a Linux distribution out there designed to emulate crufty old Unix as closely as possible. :-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Wed, 24 Jul 2002, at 10:59am, [EMAIL PROTECTED] wrote: The iterations of Linux distros have some major bugs in them. It's more accurate, and much more general :) Might as well be completely honest: The various iterations of most software have some major bugs in them. Or, to use my preferred quote: If builders designed buildings the way programmers write programs, the first wood pecker to come along would have destroyed civilization. -- Gerald Weinberg However, as you point out, at least with Linux, not only can be do something about it, but we can expect a fix within a reasonable amount of time ... I say that a lot. It is not that Linux is perfect. Heck, even typing that makes me laugh! No, the advantage Linux has is that one can find and fix the problems a heck of a lot quicker and easier on Linux than on a commercial OS. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
[EMAIL PROTECTED] said:
On Wed, 24 Jul 2002, at 10:55am, [EMAIL PROTECTED] wrote:
... espoused by Evi Nemeth, et al, in the UNIX/Linux System
Administrator's Handbook series. RH violates these basic practices with
their configurations many times.
Heh. My take on the same thing was that USAH didn't get many things
about Linux and GNU. :-) The biggest being: GNU's Not Unix. There are
times where Red Hat (and others) have decided not to perpetuate certain
braindamages from traditional Unix. I, for one, am thankful for that in
many cases. Yes, it sometimes causes older software to break. The answer
is to fix the software.
Ever read The Unix Hater's Handbook? It's got some very good points
about the flaws in Unix. I think it's pre-Linux and many of the things
it complains about had been fixed by the time I read it ('92). Some of
the things have been fixed but the old versions are still distributed by
the Unix vendors.
--
---
Tom Buskey
*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*
Re: automated installation
go to http://www.finley.org (or finley.com.. i forget)... and look for system imager That oughta do it... J. On Tue, 23 Jul 2002, Michael O'Donnell wrote: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. For example, one scheme I've heard of (but have been unable to find at scyld.com or anywhere else) was reportedly developed by the Scyld Beowolf folks and it sounded very interesting - you could supposedly insert a Scyld CD into each one of a bunch of machines on your net, boot each machine from its CD, designate one machine as Master, and they'd all then cooperatively initialize themselves, install the software onto their local disks and start cranking as a Beowolf cluster. Although I'm not working with Beowolf I am involved with clustered systems so such a scheme sounds like it might be of interest - can anybody supply any details, or recommend any other approach to automated, net-based, multi-system installation? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Joshua S. Freeman | preferred email: [EMAIL PROTECTED] pgp public key: finger [EMAIL PROTECTED] http://www.threeofus.com -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
We've used System Imager here with fairly good success. It's a bit like Solaris's jumpstart, so your machines need to have the ability to boot off the network, but it's pretty straightforward other than that. I've been toying around with partition image as well, which looks a little better to me, but I haven't gotten deep into it yet, so I can't vouch for its functionality. http://systemimager.sourceforge.net/ http://www.partimage.org/ Ben On Tue, 23 Jul 2002, Michael O'Donnell wrote: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. For example, one scheme I've heard of (but have been unable to find at scyld.com or anywhere else) was reportedly developed by the Scyld Beowolf folks and it sounded very interesting - you could supposedly insert a Scyld CD into each one of a bunch of machines on your net, boot each machine from its CD, designate one machine as Master, and they'd all then cooperatively initialize themselves, install the software onto their local disks and start cranking as a Beowolf cluster. Although I'm not working with Beowolf I am involved with clustered systems so such a scheme sounds like it might be of interest - can anybody supply any details, or recommend any other approach to automated, net-based, multi-system installation? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- Better to do a good deed near at home than go far away to burn incense. * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
[EMAIL PROTECTED] (Michael O'Donnell) writes: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. Would yet another Outlook virus solve your problem here? It'd be painless and automated, right? (-: --kevin -- Outlook not so good. That magic 8-ball knows everything! I'll ask about Exchange Server next. -- sharkey's .signature on Slashdot * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
You might want to check out the System Installer Suite at http://sisuite.org/ . VA also had something like this a while back, but I can't remember the name. It allowed you to have a Gold system, which was the one you wanted everything else to look like. Then you had the master server that monitored the gold server and informed clients of any changes. Does anyone remember what that one was called? C-Ya, Kenny On Tue, 2002-07-23 at 14:08, Michael O'Donnell wrote: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. For example, one scheme I've heard of (but have been unable to find at scyld.com or anywhere else) was reportedly developed by the Scyld Beowolf folks and it sounded very interesting - you could supposedly insert a Scyld CD into each one of a bunch of machines on your net, boot each machine from its CD, designate one machine as Master, and they'd all then cooperatively initialize themselves, install the software onto their local disks and start cranking as a Beowolf cluster. Although I'm not working with Beowolf I am involved with clustered systems so such a scheme sounds like it might be of interest - can anybody supply any details, or recommend any other approach to automated, net-based, multi-system installation? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Tue, 23 Jul 2002, at 2:08pm, Michael O'Donnell wrote: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. Others have provided many good suggestions. There is also Kickstart, if you are using Red Hat. See manual pages mkkickstart(8) and/or ksconfig(8). -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Tue, Jul 23, 2002 at 02:21:55PM -0400, Ben Boulanger wrote: We've used System Imager here with fairly good success. It's a bit like Solaris's jumpstart, so your machines need to have the ability to boot off the network, but it's pretty straightforward other than that. You can use etherboot to create a bootable CD/floppy that would do the same thing as netboot/PXEboot. For a large number of machines, it was easier to do it that way then constantly change the BIOS settings to prevent it from booting from the network each time it started. -Mark * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Tue, Jul 23, 2002 at 02:35:49PM -0400, [EMAIL PROTECTED] wrote: On Tue, 23 Jul 2002, at 2:08pm, Michael O'Donnell wrote: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. Others have provided many good suggestions. There is also Kickstart, if you are using Red Hat. See manual pages mkkickstart(8) and/or ksconfig(8). Every time I've used kickstart, there has been some serious bug in it. From messing up the partition table to mismatches between crypt/shadow/plaintext root password settings. Then again, I haven't tried kickstart since the late 6.x series. -Mark * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
Would yet another Outlook virus solve your problem here? It'd be painless and automated, right? (-: Heh. Now *that* is Market Penetration. (as in, bend over ) * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Tue, 23 Jul 2002 14:08:49 -0400 Michael O'Donnell [EMAIL PROTECTED] wrote: I'm looking for an automated software installation mechanism - I want to be able to deliver software to my customers in such a way that they can install it on multiple machines as painlessly as possible. I think the Beowulf thingy you're talking about is called FAI, or, Fully Automated Installation. It's currently restricted to debian installs, and was originally intended for Beowulf clusters, however it's been more abstracted at this point to be a generic installation utility much in the way of Solaris' JumpStart. It's actually much closer to JS than SI is. SI seems to depend upon the concept of gold or pristine images which are then copied across the net to the client. FAI is more like JS and KS in that it's actually an over the net, package-by-package install of the OS. Additionally, it's completely configurable by designing your environment such that every machine which gets installed by FAI falls into a class of machine. Depending upon the class of machine the client falls into, determines things like IP addresses, number of ethernet interfaces, disk partitioning schemes, NIS domains, etc. There is absolutely nothing that is not configurable with FAI. For instance, I am currently mucking around with FAI, and I have 2 classes of machines I care about, one which has 4 80GB drives, and another with 4 160GB drives. Soon, I'll have one with 4 250GB drives. The only thing among the hardware which differs is the size of the drives. This affect my drive partitioning scheme, so that the 80GB drives get partitioned differently than the 160s and 250s. Additionally, if I had machines with differing amounts of RAM, I could set it up so depending upon the amount of RAM and the size of the drives, I could do things like pre-determine the amount of swap I need. So an 80GB drive system with 1GB of memory might be configured with less swap than a 250GB drive system with 128MB of memory, etc. Also, machines can fall into multiple classes and depending upon which classes are defined for a given client, different things can happen at install time. Currently, as I said, it's meant to work only with Debian, but supposedly there is effort underway to use it with RH systems and Solaris. Currently it will work to install Debian on Sparc, though :) Another thing you may wish to look at is cfengine. It's not really an automated install utility, but can be used that way. Oh, FAI will work with PXE boot, as well as boot floppies. I'm sitting in a training class right now not on my own system, so I don't have any URLs for you, but Freshmeat should have links for both FAI and cfengine, if not, google :) HTH, Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: automated installation
On Tue, 23 Jul 2002, at 2:34pm, Mark Komarinski wrote: Every time I've used kickstart, there has been some serious bug in it. From messing up the partition table to mismatches between crypt/shadow/plaintext root password settings. The early iterations of Red Hat's anaconda install did have some serious bugs in them. For that matter, some of the later iterations have, too. However, said bugs have typically been fixed with the release of updated install images from Red Hat. It usually takes Red Hat two or three tries to get something right, but they usually do get it right, eventually. ;-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
