From herta.vandeneynde at gmail.com Mon Jul 7 11:50:23 2008 From: herta.vandeneynde at gmail.com (Herta Van den Eynde) Date: Mon, 7 Jul 2008 13:50:23 +0200 Subject: "installation method" RHEL 5.2 Message-ID: I'm trying to install Red Hat EL 5.2 on a Dell PE 1850 via the DRAC 4 card, with rhel-5.2-server-i386-disc1.iso mounted as virtual media. At the boot prompt, I hit , which should start the graphical installation, but it starts off with a text installation. I am asked - whether I want to test the media, which I skip - what language I want to use - I select "English" - what keyboard I have - I select "us" - the installation method - "What type of media contains the packages to be installed?" I have the choice between - Local CDROM - Hard drive - NFS image - FTP - HTTP but not virtual CDROM. How can I get it to install from the virtual CDROM? Choosing "Local CDROM" doesn't work. It returns: The Read Hat Enterprise Linux Server CD was not found in any of your CDROM drives. Please insert the Red Hat Enterprise Linux Server CD and press OK to retry. Why is the question there in the first place? It got that far using the virtual media, so why not simply continue using it? Kind regards, Herta -- "Life on Earth may be expensive, but it comes with a free ride around the Sun." From chet.nichols at gmail.com Mon Jul 7 13:18:09 2008 From: chet.nichols at gmail.com (Chet Nichols III) Date: Mon, 7 Jul 2008 09:18:09 -0400 Subject: "installation method" RHEL 5.2 In-Reply-To: References: Message-ID: > > Why is the question there in the first place? It got that far using > the virtual media, so why not simply continue using it? > Your virtual media might be a boot ISO whose only job is to boot the machine (as a virtual CD-ROM) into a kickstart install using packages that you'll grab over HTTP. As for why it's giving you that issue, not a clue at all- never had that issue before, sorry! Chet -- ---------------------------------------- chet nichols III chet.nichols at gmail.com aim: chet / twitter: chet http://chetnichols.org ---------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From herta.vandeneynde at gmail.com Mon Jul 7 13:32:22 2008 From: herta.vandeneynde at gmail.com (Herta Van den Eynde) Date: Mon, 7 Jul 2008 15:32:22 +0200 Subject: "installation method" RHEL 5.2 In-Reply-To: References: Message-ID: 2008/7/7 Chet Nichols III : >> Why is the question there in the first place? It got that far using >> the virtual media, so why not simply continue using it? > > Your virtual media might be a boot ISO whose only job is to boot the machine > (as a virtual CD-ROM) into a kickstart install using packages that you'll > grab over HTTP. > > As for why it's giving you that issue, not a clue at all- never had that > issue before, sorry! > > Chet > > -- > ---------------------------------------- > chet nichols III > chet.nichols at gmail.com > aim: chet / twitter: chet > http://chetnichols.org > ---------------------------------------- Thanks, Chet. I never had the issue before either. It seems to work just fine with the Red Hat 5.1 iso. :-( Kind regards, Herta -- "Life on Earth may be expensive, but it comes with a free ride around the Sun." From dongwu at yahoo-inc.com Mon Jul 7 17:05:18 2008 From: dongwu at yahoo-inc.com (Dongwu Zeng) Date: Mon, 07 Jul 2008 10:05:18 -0700 Subject: "installation method" RHEL 5.2 In-Reply-To: Message-ID: I guess that the first reading from CD-ROM is done through driver provide by BIOS. When RHEL asks for installation media, it tries to use driver provided by Linux. It seems that Linux or RHEL in this case doesn't have driver for your "virtual Cd-ROM". I had similar problem before when I tried to use USB CD-ROM to install RHEL. You need to somehow specify the correct driver during installation. Dongwu On 7/7/08 6:32 AM, "Herta Van den Eynde" wrote: > 2008/7/7 Chet Nichols III : >>> Why is the question there in the first place? It got that far using >>> the virtual media, so why not simply continue using it? >> >> Your virtual media might be a boot ISO whose only job is to boot the machine >> (as a virtual CD-ROM) into a kickstart install using packages that you'll >> grab over HTTP. >> >> As for why it's giving you that issue, not a clue at all- never had that >> issue before, sorry! >> >> Chet >> >> -- >> ---------------------------------------- >> chet nichols III >> chet.nichols at gmail.com >> aim: chet / twitter: chet >> http://chetnichols.org >> ---------------------------------------- > Thanks, Chet. > > I never had the issue before either. It seems to work just fine with > the Red Hat 5.1 iso. :-( > > Kind regards, > > Herta From chet.nichols at gmail.com Mon Jul 7 20:25:10 2008 From: chet.nichols at gmail.com (Chet Nichols III) Date: Mon, 7 Jul 2008 16:25:10 -0400 Subject: "installation method" RHEL 5.2 In-Reply-To: References: Message-ID: I had previously had an issue with an iLO card on an HP that was also giving me virtual media issues- turns out I just needed to update the iLO firmware. I would say maybe you need to update your DRAC firmware, but you said it works fine with RHEL5.1, just not 5.2? Have you tried using your 5.2 disc on a local machine to confirm it works? I guess that's kind of an obvious suggestion, but you never know :D Chet On Mon, Jul 7, 2008 at 1:05 PM, Dongwu Zeng wrote: > > I guess that the first reading from CD-ROM is done through driver provide > by > BIOS. When RHEL asks for installation media, it tries to use driver > provided > by Linux. It seems that Linux or RHEL in this case doesn't have driver for > your "virtual Cd-ROM". I had similar problem before when I tried to use USB > CD-ROM to install RHEL. You need to somehow specify the correct driver > during installation. > > Dongwu > > > On 7/7/08 6:32 AM, "Herta Van den Eynde" > wrote: > > > 2008/7/7 Chet Nichols III : > >>> Why is the question there in the first place? It got that far using > >>> the virtual media, so why not simply continue using it? > >> > >> Your virtual media might be a boot ISO whose only job is to boot the > machine > >> (as a virtual CD-ROM) into a kickstart install using packages that > you'll > >> grab over HTTP. > >> > >> As for why it's giving you that issue, not a clue at all- never had that > >> issue before, sorry! > >> > >> Chet > >> > >> -- > >> ---------------------------------------- > >> chet nichols III > >> chet.nichols at gmail.com > >> aim: chet / twitter: chet > >> http://chetnichols.org > >> ---------------------------------------- > > Thanks, Chet. > > > > I never had the issue before either. It seems to work just fine with > > the Red Hat 5.1 iso. :-( > > > > Kind regards, > > > > Herta > > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > -- ---------------------------------------- chet nichols III chet.nichols at gmail.com aim: chet / twitter: chet http://chetnichols.org ---------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From herta.vandeneynde at gmail.com Tue Jul 8 09:21:33 2008 From: herta.vandeneynde at gmail.com (Herta Van den Eynde) Date: Tue, 8 Jul 2008 11:21:33 +0200 Subject: "installation method" RHEL 5.2 In-Reply-To: References: Message-ID: I md5sum'ed the image and also had it checked by the installation script. They both came back OK. I currently don't have another system to test this on, but I can hardly imagine I'd be the first to use this. And things are getting curiouser and curiouser. After installing 5.1, I mounted the 5.1 iso image through DRAC. /var/log/messages reports "Jul 8 12:56:23 dsrv546 kernel: cdrom: This disc doesn't have any tracks I recognize!" But if I connect the 5.2 iso image, nothing gets logged - and nothing gets automount'ed either. Kind regards, Herta 2008/7/7 Chet Nichols III : > I had previously had an issue with an iLO card on an HP that was also giving > me virtual media issues- turns out I just needed to update the iLO > firmware. > > I would say maybe you need to update your DRAC firmware, but you said it > works fine with RHEL5.1, just not 5.2? Have you tried using your 5.2 disc on > a local machine to confirm it works? I guess that's kind of an obvious > suggestion, but you never know :D > > Chet > > On Mon, Jul 7, 2008 at 1:05 PM, Dongwu Zeng wrote: >> >> I guess that the first reading from CD-ROM is done through driver provide >> by >> BIOS. When RHEL asks for installation media, it tries to use driver >> provided >> by Linux. It seems that Linux or RHEL in this case doesn't have driver for >> your "virtual Cd-ROM". I had similar problem before when I tried to use >> USB >> CD-ROM to install RHEL. You need to somehow specify the correct driver >> during installation. >> >> Dongwu >> >> >> On 7/7/08 6:32 AM, "Herta Van den Eynde" >> wrote: >> >> > 2008/7/7 Chet Nichols III : >> >>> Why is the question there in the first place? It got that far using >> >>> the virtual media, so why not simply continue using it? >> >> >> >> Your virtual media might be a boot ISO whose only job is to boot the >> >> machine >> >> (as a virtual CD-ROM) into a kickstart install using packages that >> >> you'll >> >> grab over HTTP. >> >> >> >> As for why it's giving you that issue, not a clue at all- never had >> >> that >> >> issue before, sorry! >> >> >> >> Chet >> >> >> >> -- >> >> ---------------------------------------- >> >> chet nichols III >> >> chet.nichols at gmail.com >> >> aim: chet / twitter: chet >> >> http://chetnichols.org >> >> ---------------------------------------- >> > Thanks, Chet. >> > >> > I never had the issue before either. It seems to work just fine with >> > the Red Hat 5.1 iso. :-( >> > >> > Kind regards, >> > >> > Herta >> >> -- >> redhat-sysadmin-list mailing list >> redhat-sysadmin-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > > > > -- > ---------------------------------------- > chet nichols III > chet.nichols at gmail.com > aim: chet / twitter: chet > http://chetnichols.org > ---------------------------------------- > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > -- "Life on Earth may be expensive, but it comes with a free ride around the Sun." From okasion at gmail.com Tue Jul 8 20:26:01 2008 From: okasion at gmail.com (okasion) Date: Tue, 8 Jul 2008 17:26:01 -0300 Subject: "installation method" RHEL 5.2 Message-ID: Correct, I had the same issue on a brand new server with a Mitsuva DVD reader that could boot FreeBSD 7 but when it came to the point of selecting the installation media, couldnt recognize the DVD reader, the same happened with Debian Etch; however, RHEL 5 managed to boot and recogniz the DVD reader without problems. On 7/7/08 6:32 AM, "Herta Van den Eynde" wrote: > 2008/7/7 Chet Nichols III : >>> Why is the question there in the first place? It got that far using >>> the virtual media, so why not simply continue using it? >> >> Your virtual media might be a boot ISO whose only job is to boot the machine >> (as a virtual CD-ROM) into a kickstart install using packages that you'll >> grab over HTTP. >> >> As for why it's giving you that issue, not a clue at all- never had that >> issue before, sorry! >> >> Chet >> >> -- >> ---------------------------------------- >> chet nichols III >> chet.nichols at gmail.com >> aim: chet / twitter: chet >> http://chetnichols.org >> ---------------------------------------- > Thanks, Chet. > > I never had the issue before either. It seems to work just fine with > the Red Hat 5.1 iso. :-( > > Kind regards, > > Herta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Mooney at ndsu.edu Tue Jul 8 22:27:29 2008 From: Tim.Mooney at ndsu.edu (Tim Mooney) Date: Tue, 8 Jul 2008 17:27:29 -0500 (CDT) Subject: tuning nscd on RHEL 5.x Message-ID: All- I'm looking for some advice on using and tuning nscd on RHEL 5.2. We have several IMAP mail servers running RHEL 5.2, each with somewhere between 3000 and 7000 /etc/passwd entries. On a busy mail system, there are a few processes (sendmail, procmail, the imapd processes, et. al.) that will be making getpwnam() and other calls frequently, so nscd caching seems like it could be a big win. Our customers can only access the IMAP systems via IMAP. Using nscd -g after the systems have been up for a while, the default hit rates for passwd, group, and hosts is pretty low -- generally less than 10% for passwd and even less (usually 0%) for group and hosts. This is mainly because the default (prime) "suggested size" parameter from /etc/nscd.conf is 211, much too small for a box with this many entries in /etc/passwd. I increased it to 1987 (the year I graduated from high school...) and restarted nscd on one of the boxes, and that's helped the cache hit rate for the passwd category (it sometimes makes it into the 40% range), but hasn't done much for group or hosts. I'm now left with a few questions and observations: - what tuning have others done to improve the cache hit rates with nscd? - in particular, beyond increasing the suggested size, have you increased the durations that positive or negative hits are cached? - on the one system where I increased the suggested size, I've now had nscd apparently die on a couple different occassions. Since nscd can't dump core (it can't write to /, its CWD), I don't have any core files to show for it. Anyone else that's tuned nscd having it exit periodically? - I've seen recommendations to not even bother with caching the hosts, and to just run caching nameservers instead (which we do elsewhere). Anyone care to comment on that? - we run a nightly script on our IMAP boxes to purge email older than 30 days in each person's "Spam-Quarantine" folders. The script uses sudo to switch to the user and then run the command to prune old email: sudo -H -u ${THEUSER} /usr/local/sbin/mailutil \ prune ${POTENTIAL} \ "before ${DATE_THIRTY_DAYS_AGO}" 1> /dev/null A few times a week, that cron job outputs a message of the form sudo: no passwd entry for joeuser! even though joeuser has a passwd file entry. I'm suspicious this is nscd screwing up and returning something like ENOENT in certain rare conditions, even though the user most certainly does exist in /etc/passwd. Anyone seen this behavior? Thanks, Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 From smooge at gmail.com Tue Jul 8 22:39:30 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 8 Jul 2008 16:39:30 -0600 Subject: tuning nscd on RHEL 5.x In-Reply-To: References: Message-ID: <80d7e4090807081539g1ff5f2d2va7a3b56fa7ed5101@mail.gmail.com> On Tue, Jul 8, 2008 at 4:27 PM, Tim Mooney wrote: > > All- > > I'm looking for some advice on using and tuning nscd on RHEL 5.2. > > We have several IMAP mail servers running RHEL 5.2, each with somewhere > between 3000 and 7000 /etc/passwd entries. > > On a busy mail system, there are a few processes (sendmail, procmail, > the imapd processes, et. al.) that will be making getpwnam() and other > calls frequently, so nscd caching seems like it could be a big win. > Our customers can only access the IMAP systems via IMAP. > > Using > > nscd -g > > after the systems have been up for a while, the default hit rates for > passwd, group, and hosts is pretty low -- generally less than 10% for > passwd and even less (usually 0%) for group and hosts. > > This is mainly because the default (prime) "suggested size" parameter from > /etc/nscd.conf is 211, much too small for a box with this many entries in > /etc/passwd. I increased it to 1987 (the year I graduated from high > school...) and restarted nscd on one of the boxes, and that's helped the > cache hit rate for the passwd category (it sometimes makes it into the 40% > range), but hasn't done much for group or hosts. > > I'm now left with a few questions and observations: > > - what tuning have others done to improve the cache hit rates with nscd? > - in particular, beyond increasing the suggested size, have you > increased the durations that positive or negative hits are cached? > > - on the one system where I increased the suggested size, I've now > had nscd apparently die on a couple different occassions. Since nscd > can't dump core (it can't write to /, its CWD), I don't have any core > files to show for it. > > Anyone else that's tuned nscd having it exit periodically? > We have had nscd 'exit' periodically even when not tuned. I actually had not thought of tuning it which would probably fix a couple of problems I have been seeing (duh). > - I've seen recommendations to not even bother with caching the hosts, and > to just run caching nameservers instead (which we do elsewhere). Anyone > care to comment on that? > That is what we did.. it helps for dynamic dns environments. > - we run a nightly script on our IMAP boxes to purge email older than > 30 days in each person's "Spam-Quarantine" folders. The script uses > sudo to switch to the user and then run the command to prune old email: > > sudo -H -u ${THEUSER} /usr/local/sbin/mailutil \ > prune ${POTENTIAL} \ > "before ${DATE_THIRTY_DAYS_AGO}" 1> /dev/null > > A few times a week, that cron job outputs a message of the form > > sudo: no passwd entry for joeuser! > > even though joeuser has a passwd file entry. > > I'm suspicious this is nscd screwing up and returning something like > ENOENT in certain rare conditions, even though the user most certainly > does exist in /etc/passwd. > > Anyone seen this behavior? > yes we have seen this.. we normally have to do a nscd reload on the box when it happens. > Thanks, > > Tim > -- > Tim Mooney Tim.Mooney at ndsu.edu > Enterprise Computing & Infrastructure 701-231-1076 (Voice) > Room 242-J6, IACC Building 701-231-8541 (Fax) > North Dakota State University, Fargo, ND 58105-5164 > > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Tim.Mooney at ndsu.edu Wed Jul 9 16:20:53 2008 From: Tim.Mooney at ndsu.edu (Tim Mooney) Date: Wed, 9 Jul 2008 11:20:53 -0500 (CDT) Subject: securing RHEL 5.x in a university lab setting Message-ID: All- We've been running a lab of Linux workstations for our students for several years, and in the past I've felt pretty confident that we had the systems well-secured. I think it was easier in the past, though, because the systems weren't quite so "user friendly". I'm planning on kickstarting the lab with RHEL 5.2 in the next few weeks. With RHEL 5.x and the GNOME/KDE environment that comes with it and some of the newer components (e.g. HAL), I'm concerned that there may be new things that I need to do to prevent the lab users from being able to compromise the security of the systems. Having physical access to the systems always makes security more tricky... We're still doing all the basics (BIOS & grub passwords to control what can be booted, etc.). My primary new concern is with making sure that students can bring in media (USB sticks, CDs, etc.) and get it mounted without also being able to make use of setuid binaries they may have placed on the media they bring in. With that in mind, anyone have any good pointers for securing the graphical desktops and HAL against possible attackers with physical access? More generally, anyone know of a good guide or checklist for securing RHEL 5.x in a university lab? Thanks, Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 From smooge at gmail.com Wed Jul 9 16:26:10 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 9 Jul 2008 10:26:10 -0600 Subject: securing RHEL 5.x in a university lab setting In-Reply-To: References: Message-ID: <80d7e4090807090926w5f10bab1y46bcafa1b18535d6@mail.gmail.com> On Wed, Jul 9, 2008 at 10:20 AM, Tim Mooney wrote: > > All- > > We've been running a lab of Linux workstations for our students for > several years, and in the past I've felt pretty confident that we had > the systems well-secured. I think it was easier in the past, though, > because the systems weren't quite so "user friendly". > > I'm planning on kickstarting the lab with RHEL 5.2 in the next few weeks. > With RHEL 5.x and the GNOME/KDE environment that comes with it and some > of the newer components (e.g. HAL), I'm concerned that there may be new > things that I need to do to prevent the lab users from being able to > compromise the security of the systems. Having physical access to the > systems always makes security more tricky... > > We're still doing all the basics (BIOS & grub passwords to control what > can be booted, etc.). My primary new concern is with making sure that > students can bring in media (USB sticks, CDs, etc.) and get it mounted > without also being able to make use of setuid binaries they may have > placed on the media they bring in. > > With that in mind, anyone have any good pointers for securing the > graphical desktops and HAL against possible attackers with physical > access? More generally, anyone know of a good guide or checklist > for securing RHEL 5.x in a university lab? > Hi Tim I haven't dealt with this in 2 years so I am off.. but there is a way to tell hal that usb keys are mounted nosuid. [Actually i think that is the default.. but I can't remember]. The CIS or NSA guides might have the actual steps to do that.. sorry I can't help mroe. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Enils.Bashi at FTIConsulting.com Wed Jul 9 16:41:27 2008 From: Enils.Bashi at FTIConsulting.com (Bashi, Enils) Date: Wed, 9 Jul 2008 12:41:27 -0400 Subject: securing RHEL 5.x in a university lab setting In-Reply-To: References: Message-ID: <1DC970238492C74884BD8B98C188B099016319B4@ANNMX27.na.fti.local> Tim, Once you give someone physical access to a box, the sky is the limit, unless you're boxes will have full disk encryption. Savvy users will always find ways to bypass your security controls. The question is, what is your risk tolerance? The answer that question should drive the effort you will put into securing those workstations. That said, here are a couple of guides I have used in our corporate environment to secure RHEL servers: http://www.nsa.gov/snac/os/redhat/rhel5-guide-i731.pdf http://www.cisecurity.org/tools2/linux/CIS_RHEL5_Benchmark_v1.1.pdf If you have the option, my suggestion would be to run Xen virtual machines and save a vanilla snapshot with all your desired settings. Let your students do pretty much whatever they want and restart the workstations every time someone logs off, in order to restore the vanilla snapshot every time. This will give you the most secure option in my opinion. Regards, Enils Bashi, RHCE, CISSP Sr. Security Engineer\Information Technology Group F T I 410.571.7003 direct 906 Commerce Road Annapolis, MD 21401 www.fticonsulting.com Confidentiality Notice: This email and any attachments may be confidential and protected by legal privilege. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the e-mail or any attachment is prohibited. If you have received this email in error, please notify us immediately by replying to the sender and then delete this copy and the reply from your system. Thank you for your cooperation. -----Original Message----- From: redhat-sysadmin-list-bounces at redhat.com [mailto:redhat-sysadmin-list-bounces at redhat.com] On Behalf Of Tim Mooney Sent: Wednesday, July 09, 2008 12:21 PM To: redhat-sysadmin-list at redhat.com Subject: securing RHEL 5.x in a university lab setting All- We've been running a lab of Linux workstations for our students for several years, and in the past I've felt pretty confident that we had the systems well-secured. I think it was easier in the past, though, because the systems weren't quite so "user friendly". I'm planning on kickstarting the lab with RHEL 5.2 in the next few weeks. With RHEL 5.x and the GNOME/KDE environment that comes with it and some of the newer components (e.g. HAL), I'm concerned that there may be new things that I need to do to prevent the lab users from being able to compromise the security of the systems. Having physical access to the systems always makes security more tricky... We're still doing all the basics (BIOS & grub passwords to control what can be booted, etc.). My primary new concern is with making sure that students can bring in media (USB sticks, CDs, etc.) and get it mounted without also being able to make use of setuid binaries they may have placed on the media they bring in. With that in mind, anyone have any good pointers for securing the graphical desktops and HAL against possible attackers with physical access? More generally, anyone know of a good guide or checklist for securing RHEL 5.x in a university lab? Thanks, Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- redhat-sysadmin-list mailing list redhat-sysadmin-list at redhat.com https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7443 bytes Desc: not available URL: From Jeffrey.Thomas at sierra-bravo.com Wed Jul 9 18:59:51 2008 From: Jeffrey.Thomas at sierra-bravo.com (Jeffrey G Thomas) Date: Wed, 9 Jul 2008 13:59:51 -0500 Subject: CIFS error: "mount error 11" Message-ID: <200807091359.51080.Jeffrey.Thomas@sierra-bravo.com> I cannot mount a Windows2003 Enterprise share on my Redhat 5.1 server. Nearly every time, the mount fails, but the few times it has worked I've done nothing differently. My /etc/fstab entry: > \\192.168.35.11\Backups /mnt/backups cifs credentials=/root/.cred,noauto,gid=500,uid=500,file_mode=0777,dir_mode=0777,rw 0 0 Sometimes the mounting works but usually is does not, giving the error: > [root at rhel51 ~]# mount /mnt/backups/ > mount error 11 = Resource temporarily unavailable > Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) which clarifies nothing for me. If I change the fstab entry to 'smbfs', I get this error: > [root at rhel51 ~]# mount /mnt/backups/ > mount: unknown filesystem type 'smbfs' I am not sure if these are related or not, from /var/log/samba/smbd.log: > [2008/07/09 13:24:38, 0] auth/auth_util.c:create_builtin_administrators(792) > create_builtin_administrators: Failed to create Administrators > [2008/07/09 13:24:38, 0] auth/auth_util.c:create_builtin_users(758) > create_builtin_users: Failed to create Users > [2008/07/09 13:27:49, 0] auth/auth_util.c:create_builtin_administrators(792) > create_builtin_administrators: Failed to create Administrators > [2008/07/09 13:27:49, 0] auth/auth_util.c:create_builtin_users(758) > create_builtin_users: Failed to create Users ...and from /var/log/samba/wb-NETBIOSNAME.log > [2008/07/09 13:27:49, 0] nsswitch/winbindd_passdb.c:sid_to_name(130) > Possible deadlock: Trying to lookup SID S-1-1-0 with passdb backend > [2008/07/09 13:27:49, 0] nsswitch/winbindd_passdb.c:sid_to_name(130) > Possible deadlock: Trying to lookup SID S-1-5-2 with passdb backend Can anyone help me with this? The kernel is: > 2.6.18-53.1.6.el5 #1 SMP .... x86_64 x86_64 x86_64 GNU/Linux From dag at wieers.com Mon Jul 14 12:43:56 2008 From: dag at wieers.com (Dag Wieers) Date: Mon, 14 Jul 2008 14:43:56 +0200 (CEST) Subject: "installation method" RHEL 5.2 In-Reply-To: References: Message-ID: On Mon, 7 Jul 2008, Herta Van den Eynde wrote: > Why is the question there in the first place? It got that far using > the virtual media, so why not simply continue using it? Herta, I bet the RHEL5 list is a better venue to ask this question as more people (from Red Hat) are monitoring that one: rhelv5-list at redhat.com Besides it is more on-topic on that list. PS Also I think this is worth a bug-report in bugzilla or the customer ticketing system as it seems to be genuine bug with the (virtual) CD-ROM interface (either with the Linux driver or a combination of the Linux driver and DRAC). And bugzilla is a good way to draw a crowd having the same problem. :-) -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dlopez at humnet.ucla.edu Thu Jul 17 23:17:42 2008 From: dlopez at humnet.ucla.edu (Lopez, Denise) Date: Thu, 17 Jul 2008 16:17:42 -0700 Subject: Re-initialize Luci database Message-ID: Hi all, I was just wondering if there was a way to re-initialize a luci database installation. I am trying to setup a 2 node cluster and keep getting "error retrieving batch xxxxxxx information" Also noticed a "Configuration Version" error so I wanted to recreate the luci database and start over. Thanks in advance. Denise Lopez UCLA - Center for Digital Humanities Network Services Linux Systems Engineer 337 Charles E. Young Drive East PPB 1020 Los Angeles, CA 90095-1499 310/206-8216 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2230 bytes Desc: image001.jpg URL: From schilling2006 at gmail.com Sat Jul 19 14:22:32 2008 From: schilling2006 at gmail.com (schilling) Date: Sat, 19 Jul 2008 10:22:32 -0400 Subject: NTPD catches in RHEL Server 5? Message-ID: Hi, I was trying to upgrade my ntp server from AS 3 w/ ntp-4.1.2-5.el3 to RHEL server 5 w/ntp-4.2.2p1-8.el5, I copied the /etc/ntp.conf and iptables to the new installation. But now the RHEL5 will not providing the NTP services. Is there any cactch configuration for RHEL 5? My configuration is as follows: [test at dns1 ~]$ more /etc/ntp.conf # Prohibit general access to this service. #restrict default ignore # Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 #On Campus Peers #peer 192.168.8.8 peer 10.10.121.44 # -- CLIENT NETWORK ------- # Permit systems on this network to synchronize with this # time service. Do not permit those systems to modify the # configuration of this service. Also, do not use those # systems as peers for synchronization. restrict 192.168.0.0 mask 255.255.0.0 notrust nomodify notrap restrict 10.10.0.0 mask 255.255.0.0 notrust nomodify notrap # --- OUR TIMESERVERS ----- # or remove the default restrict line # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. # restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery # server mytrustedtimeserverip server 18.145.0.30 #NAVOBS1.MIT.EDU. server 128.118.25.12 #gps1.tns.its.psu.edu. server 192.5.41.209 #ntp2.usno.navy.mil. server 192.5.41.40 #tick.usno.navy.mil. restrict 18.145.0.30 mask 255.255.255.255 nomodify notrap noquery restrict 128.118.25.12 mask 255.255.255.255 nomodify notrap noquery restrict 192.5.41.209 mask 255.255.255.255 nomodify notrap noquery restrict 192.5.41.40 mask 255.255.255.255 nomodify notrap noquery # --- NTP MULTICASTCLIENT --- #multicastclient # listen on default 224.0.1.1 # restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap # restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap # --- GENERAL CONFIGURATION --- # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # #server 127.127.1.0 # local clock #fudge 127.127.1.0 stratum 10 # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /var/lib/ntp/drift broadcastdelay 0.008 # # Authentication delay. If you use, or plan to use someday, the # authentication facility you should make the programs in the auth_stuff # directory and figure out what this number should be on your machine. # #authenticate yes # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 600 for sure) and define the key number to be # used for making requests. # # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. Note also that # ntpd is started with a -A flag, disabling authentication, that # will have to be removed as well. # keys /etc/ntp/keys Thanks. Schilling -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Sun Jul 20 04:35:05 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 19 Jul 2008 22:35:05 -0600 Subject: NTPD catches in RHEL Server 5? In-Reply-To: References: Message-ID: <80d7e4090807192135s3379697fk63dc7cd836b1a382@mail.gmail.com> 2008/7/19 schilling : > > Hi, > > I was trying to upgrade my ntp server from AS 3 w/ ntp-4.1.2-5.el3 to RHEL > server 5 w/ntp-4.2.2p1-8.el5, I copied the /etc/ntp.conf and iptables to the > new installation. But now > the RHEL5 will not providing the NTP services. Is there any cactch > configuration for RHEL 5? 1. Check to see if the ntp server is running and that you can get the data locally. service ntp status 2. Check to see if the ntp server has sync'd up correctly. The newer ntp server takes a while to get a proper 'chaos' field or something ready before it will start serving time. It is a lot faster if you have a GPS etc local to it, but if it is relying on other ntp's it takes a while to give you the data. ntpq -p 3. Check to see if the firewall allows for systems to connect to port 123 on your new server. > > My configuration is as follows: > > [test at dns1 ~]$ more /etc/ntp.conf > # Prohibit general access to this service. > #restrict default ignore > > # Permit all access over the loopback interface. This could > # be tightened as well, but to do so would effect some of > # the administrative functions. > restrict 127.0.0.1 > > #On Campus Peers > #peer 192.168.8.8 > peer 10.10.121.44 > > > # -- CLIENT NETWORK ------- > # Permit systems on this network to synchronize with this > # time service. Do not permit those systems to modify the > # configuration of this service. Also, do not use those > # systems as peers for synchronization. > restrict 192.168.0.0 mask 255.255.0.0 notrust nomodify notrap > restrict 10.10.0.0 mask 255.255.0.0 notrust nomodify notrap > > # --- OUR TIMESERVERS ----- > # or remove the default restrict line > # Permit time synchronization with our time source, but do not > # permit the source to query or modify the service on this system. > > # restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap > noquery > # server mytrustedtimeserverip > > server 18.145.0.30 #NAVOBS1.MIT.EDU. > server 128.118.25.12 #gps1.tns.its.psu.edu. > server 192.5.41.209 #ntp2.usno.navy.mil. > server 192.5.41.40 #tick.usno.navy.mil. > > restrict 18.145.0.30 mask 255.255.255.255 nomodify notrap noquery > restrict 128.118.25.12 mask 255.255.255.255 nomodify notrap noquery > restrict 192.5.41.209 mask 255.255.255.255 nomodify notrap noquery > restrict 192.5.41.40 mask 255.255.255.255 nomodify notrap noquery > > > # --- NTP MULTICASTCLIENT --- > #multicastclient # listen on default 224.0.1.1 > # restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap > # restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap > > > > # --- GENERAL CONFIGURATION --- > # > # Undisciplined Local Clock. This is a fake driver intended for backup > # and when no outside source of synchronized time is available. The > # default stratum is usually 3, but in this case we elect to use stratum > # 0. Since the server line does not have the prefer keyword, this driver > # is never used for synchronization, unless no other other > # synchronization source is available. In case the local host is > # controlled by some external source, such as an external oscillator or > # another protocol, the prefer keyword would cause the local host to > # disregard all other synchronization sources, unless the kernel > # modifications are in use and declare an unsynchronized condition. > # > #server 127.127.1.0 # local clock > #fudge 127.127.1.0 stratum 10 > > # > # Drift file. Put this in a directory which the daemon can write to. > # No symbolic links allowed, either, since the daemon updates the file > # by creating a temporary in the same directory and then rename()'ing > # it to the file. > # > driftfile /var/lib/ntp/drift > broadcastdelay 0.008 > > # > # Authentication delay. If you use, or plan to use someday, the > # authentication facility you should make the programs in the auth_stuff > # directory and figure out what this number should be on your machine. > # > #authenticate yes > > # > # Keys file. If you want to diddle your server at run time, make a > # keys file (mode 600 for sure) and define the key number to be > # used for making requests. > # > # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote > # systems might be able to reset your clock at will. Note also that > # ntpd is started with a -A flag, disabling authentication, that > # will have to be removed as well. > # > keys /etc/ntp/keys > > Thanks. > > Schilling > > > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jolt at ti.com Mon Jul 21 12:36:27 2008 From: jolt at ti.com (Olt, Joseph) Date: Mon, 21 Jul 2008 07:36:27 -0500 Subject: NTPD catches in RHEL Server 5? In-Reply-To: <80d7e4090807192135s3379697fk63dc7cd836b1a382@mail.gmail.com> Message-ID: Stephen's suggestions are very good. You may also want to check the selinux permissions on the files since you copied them from another system. Are there any selinux permissions issues in the messages log? -----Original Message----- From: redhat-sysadmin-list-bounces at redhat.com [mailto:redhat-sysadmin-list-bounces at redhat.com] On Behalf Of Stephen John Smoogen Sent: Sunday, July 20, 2008 12:35 AM To: redhat-sysadmin-list at redhat.com Subject: Re: NTPD catches in RHEL Server 5? 2008/7/19 schilling : > > Hi, > > I was trying to upgrade my ntp server from AS 3 w/ ntp-4.1.2-5.el3 to RHEL > server 5 w/ntp-4.2.2p1-8.el5, I copied the /etc/ntp.conf and iptables to the > new installation. But now > the RHEL5 will not providing the NTP services. Is there any cactch > configuration for RHEL 5? 1. Check to see if the ntp server is running and that you can get the data locally. service ntp status 2. Check to see if the ntp server has sync'd up correctly. The newer ntp server takes a while to get a proper 'chaos' field or something ready before it will start serving time. It is a lot faster if you have a GPS etc local to it, but if it is relying on other ntp's it takes a while to give you the data. ntpq -p 3. Check to see if the firewall allows for systems to connect to port 123 on your new server. > > My configuration is as follows: > > [test at dns1 ~]$ more /etc/ntp.conf > # Prohibit general access to this service. > #restrict default ignore > > # Permit all access over the loopback interface. This could > # be tightened as well, but to do so would effect some of > # the administrative functions. > restrict 127.0.0.1 > > #On Campus Peers > #peer 192.168.8.8 > peer 10.10.121.44 > > > # -- CLIENT NETWORK ------- > # Permit systems on this network to synchronize with this > # time service. Do not permit those systems to modify the > # configuration of this service. Also, do not use those > # systems as peers for synchronization. > restrict 192.168.0.0 mask 255.255.0.0 notrust nomodify notrap > restrict 10.10.0.0 mask 255.255.0.0 notrust nomodify notrap > > # --- OUR TIMESERVERS ----- > # or remove the default restrict line > # Permit time synchronization with our time source, but do not > # permit the source to query or modify the service on this system. > > # restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap > noquery > # server mytrustedtimeserverip > > server 18.145.0.30 #NAVOBS1.MIT.EDU. > server 128.118.25.12 #gps1.tns.its.psu.edu. > server 192.5.41.209 #ntp2.usno.navy.mil. > server 192.5.41.40 #tick.usno.navy.mil. > > restrict 18.145.0.30 mask 255.255.255.255 nomodify notrap noquery > restrict 128.118.25.12 mask 255.255.255.255 nomodify notrap noquery > restrict 192.5.41.209 mask 255.255.255.255 nomodify notrap noquery > restrict 192.5.41.40 mask 255.255.255.255 nomodify notrap noquery > > > # --- NTP MULTICASTCLIENT --- > #multicastclient # listen on default 224.0.1.1 > # restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap > # restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap > > > > # --- GENERAL CONFIGURATION --- > # > # Undisciplined Local Clock. This is a fake driver intended for backup > # and when no outside source of synchronized time is available. The > # default stratum is usually 3, but in this case we elect to use stratum > # 0. Since the server line does not have the prefer keyword, this driver > # is never used for synchronization, unless no other other > # synchronization source is available. In case the local host is > # controlled by some external source, such as an external oscillator or > # another protocol, the prefer keyword would cause the local host to > # disregard all other synchronization sources, unless the kernel > # modifications are in use and declare an unsynchronized condition. > # > #server 127.127.1.0 # local clock > #fudge 127.127.1.0 stratum 10 > > # > # Drift file. Put this in a directory which the daemon can write to. > # No symbolic links allowed, either, since the daemon updates the file > # by creating a temporary in the same directory and then rename()'ing > # it to the file. > # > driftfile /var/lib/ntp/drift > broadcastdelay 0.008 > > # > # Authentication delay. If you use, or plan to use someday, the > # authentication facility you should make the programs in the auth_stuff > # directory and figure out what this number should be on your machine. > # > #authenticate yes > > # > # Keys file. If you want to diddle your server at run time, make a > # keys file (mode 600 for sure) and define the key number to be > # used for making requests. > # > # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote > # systems might be able to reset your clock at will. Note also that > # ntpd is started with a -A flag, disabling authentication, that > # will have to be removed as well. > # > keys /etc/ntp/keys > > Thanks. > > Schilling > > > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" -- redhat-sysadmin-list mailing list redhat-sysadmin-list at redhat.com https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list From schilling2006 at gmail.com Mon Jul 21 14:16:10 2008 From: schilling2006 at gmail.com (schilling) Date: Mon, 21 Jul 2008 10:16:10 -0400 Subject: NTPD catches in RHEL Server 5? In-Reply-To: References: <80d7e4090807192135s3379697fk63dc7cd836b1a382@mail.gmail.com> Message-ID: Figured it out. the restrict clause, notrust meaning changed dramatically. Removed the notrust from restrick clause fixed it. Thanks. Schilling On Mon, Jul 21, 2008 at 8:36 AM, Olt, Joseph wrote: > Stephen's suggestions are very good. You may also want to check the > selinux permissions on the files since you copied them from another system. > Are there any selinux permissions issues in the messages log? > > -----Original Message----- > From: redhat-sysadmin-list-bounces at redhat.com [mailto: > redhat-sysadmin-list-bounces at redhat.com] On Behalf Of Stephen John Smoogen > Sent: Sunday, July 20, 2008 12:35 AM > To: redhat-sysadmin-list at redhat.com > Subject: Re: NTPD catches in RHEL Server 5? > > 2008/7/19 schilling : > > > > Hi, > > > > I was trying to upgrade my ntp server from AS 3 w/ ntp-4.1.2-5.el3 to > RHEL > > server 5 w/ntp-4.2.2p1-8.el5, I copied the /etc/ntp.conf and iptables to > the > > new installation. But now > > the RHEL5 will not providing the NTP services. Is there any cactch > > configuration for RHEL 5? > > 1. Check to see if the ntp server is running and that you can get the > data locally. > > service ntp status > > > 2. Check to see if the ntp server has sync'd up correctly. The newer > ntp server takes a while to get a proper 'chaos' field or something > ready before it will start serving time. It is a lot faster if you > have a GPS etc local to it, but if it is relying on other ntp's it > takes a while to give you the data. > > ntpq -p > > 3. Check to see if the firewall allows for systems to connect to port > 123 on your new server. > > > > > My configuration is as follows: > > > > [test at dns1 ~]$ more /etc/ntp.conf > > # Prohibit general access to this service. > > #restrict default ignore > > > > # Permit all access over the loopback interface. This could > > # be tightened as well, but to do so would effect some of > > # the administrative functions. > > restrict 127.0.0.1 > > > > #On Campus Peers > > #peer 192.168.8.8 > > peer 10.10.121.44 > > > > > > # -- CLIENT NETWORK ------- > > # Permit systems on this network to synchronize with this > > # time service. Do not permit those systems to modify the > > # configuration of this service. Also, do not use those > > # systems as peers for synchronization. > > restrict 192.168.0.0 mask 255.255.0.0 notrust nomodify notrap > > restrict 10.10.0.0 mask 255.255.0.0 notrust nomodify notrap > > > > # --- OUR TIMESERVERS ----- > > # or remove the default restrict line > > # Permit time synchronization with our time source, but do not > > # permit the source to query or modify the service on this system. > > > > # restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap > > noquery > > # server mytrustedtimeserverip > > > > server 18.145.0.30 #NAVOBS1.MIT.EDU. > > server 128.118.25.12 #gps1.tns.its.psu.edu. > > server 192.5.41.209 #ntp2.usno.navy.mil. > > server 192.5.41.40 #tick.usno.navy.mil. > > > > restrict 18.145.0.30 mask 255.255.255.255 nomodify notrap noquery > > restrict 128.118.25.12 mask 255.255.255.255 nomodify notrap noquery > > restrict 192.5.41.209 mask 255.255.255.255 nomodify notrap noquery > > restrict 192.5.41.40 mask 255.255.255.255 nomodify notrap noquery > > > > > > # --- NTP MULTICASTCLIENT --- > > #multicastclient # listen on default 224.0.1.1 > > # restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap > > # restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap > > > > > > > > # --- GENERAL CONFIGURATION --- > > # > > # Undisciplined Local Clock. This is a fake driver intended for backup > > # and when no outside source of synchronized time is available. The > > # default stratum is usually 3, but in this case we elect to use stratum > > # 0. Since the server line does not have the prefer keyword, this driver > > # is never used for synchronization, unless no other other > > # synchronization source is available. In case the local host is > > # controlled by some external source, such as an external oscillator or > > # another protocol, the prefer keyword would cause the local host to > > # disregard all other synchronization sources, unless the kernel > > # modifications are in use and declare an unsynchronized condition. > > # > > #server 127.127.1.0 # local clock > > #fudge 127.127.1.0 stratum 10 > > > > # > > # Drift file. Put this in a directory which the daemon can write to. > > # No symbolic links allowed, either, since the daemon updates the file > > # by creating a temporary in the same directory and then rename()'ing > > # it to the file. > > # > > driftfile /var/lib/ntp/drift > > broadcastdelay 0.008 > > > > # > > # Authentication delay. If you use, or plan to use someday, the > > # authentication facility you should make the programs in the auth_stuff > > # directory and figure out what this number should be on your machine. > > # > > #authenticate yes > > > > # > > # Keys file. If you want to diddle your server at run time, make a > > # keys file (mode 600 for sure) and define the key number to be > > # used for making requests. > > # > > # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote > > # systems might be able to reset your clock at will. Note also that > > # ntpd is started with a -A flag, disabling authentication, that > > # will have to be removed as well. > > # > > keys /etc/ntp/keys > > > > Thanks. > > > > Schilling > > > > > > -- > > redhat-sysadmin-list mailing list > > redhat-sysadmin-list at redhat.com > > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > > > > > > -- > Stephen J Smoogen. -- BSD/GNU/Linux > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" > > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From briery-75827 at mypacks.net Mon Jul 21 18:23:18 2008 From: briery-75827 at mypacks.net (briery-75827 at mypacks.net) Date: Mon, 21 Jul 2008 11:23:18 -0700 (GMT-07:00) Subject: rhel4u6 able to boot/install to san. Message-ID: <12696163.1216664598852.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Is it possible/supported to boot/install from/to rhel 4u6. San is netapp, with qlogic cards. If so can you point me to link/doc's? I see that relases notes in rhel 5 say this is supported but can not find for any rhel 4. regard, rob From Kent.Rankin at orau.org Mon Jul 21 18:26:06 2008 From: Kent.Rankin at orau.org (Rankin, Kent) Date: Mon, 21 Jul 2008 14:26:06 -0400 Subject: rhel4u6 able to boot/install to san. References: <12696163.1216664598852.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Message-ID: <3B1B40BF9A684D49B927F7BE5CEE1D661B579417@zirconium.orau.net> It is possible. Who made your disk array (NetApp) doesn't matter. All that matters is your kernel supporting the correct QLA2xxx module for your QLogic FC card. This might be a helpful note: - Only enable one path for your LUN's until you get your multipathing software installed. So if you've got two HBA's with two switches and two connections to your NetApp array, just zone up one of the HBA's and one of the target WWN's on the NetApp. Once you go back and install the multipathing software, make an appropriate zone and enjoy your storage. -- Kent Rankin -----Original Message----- From: redhat-sysadmin-list-bounces at redhat.com on behalf of briery-75827 at mypacks.net Sent: Mon 7/21/2008 2:23 PM To: redhat-sysadmin-list at redhat.com Subject: rhel4u6 able to boot/install to san. Is it possible/supported to boot/install from/to rhel 4u6. San is netapp, with qlogic cards. If so can you point me to link/doc's? I see that relases notes in rhel 5 say this is supported but can not find for any rhel 4. regard, rob -- redhat-sysadmin-list mailing list redhat-sysadmin-list at redhat.com https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3237 bytes Desc: not available URL: From rsharpe at largnet.on.ca Fri Jul 25 13:19:02 2008 From: rsharpe at largnet.on.ca (Ryan Sharpe) Date: Fri, 25 Jul 2008 09:19:02 -0400 (EDT) Subject: BIND Port Randomization Message-ID: <002801c8ee59$0280e1c0$483a14c6@large2> In response to the Errta RHSA-2008:0533 I have installed the updated ISC Bind packages from Red Hat as well as updated the selinux targeted policy. However when I test the server using http://www.doxpara.com/ it still shows up as being vulnerable to DNS cache poisoning. Before this I had SELinux completely disabled, so I though I may need to turn it on. I have since set it to permissive mode and rebooted, but still the DNS source ports aren't randomizing. So again I changed the mode to enforcing, but still when I run the test it shows that I am vulnerable. What am I missing, is there a BIND directive I need? Ryan Sharpe, CCNA Technical Analyst LARG*net (519) 661-2111 x 86356 support pager: (519) 690-3216 From lists at brimer.org Fri Jul 25 13:28:00 2008 From: lists at brimer.org (Barry Brimer) Date: Fri, 25 Jul 2008 08:28:00 -0500 (CDT) Subject: BIND Port Randomization In-Reply-To: <002801c8ee59$0280e1c0$483a14c6@large2> References: <002801c8ee59$0280e1c0$483a14c6@large2> Message-ID: > In response to the Errta RHSA-2008:0533 I have installed the updated ISC > Bind packages from Red Hat as well as updated the selinux targeted policy. > However when I test the server using http://www.doxpara.com/ it still > shows up as being vulnerable to DNS cache poisoning. > > Before this I had SELinux completely disabled, so I though I may need to > turn it on. I have since set it to permissive mode and rebooted, but still > the DNS source ports aren't randomizing. So again I changed the mode to > enforcing, but still when I run the test it shows that I am vulnerable. > What am I missing, is there a BIND directive I need? The latest BIND does work with the latest SELinux packages .. in fact on RHEL 5 you *NEED* the latest SELinux packages or named is not allowed to use random ports. Make sure there is not a line in your named.conf that says "query-source address * port 53" .. that is basically instructing your named to only use port 53. If you are behind a NAT device, it may reorder the source ports being used when going through the NAT .. which is a bigger problem to fix and dependant upon your NAT vendor. Make sure that you are not doing DNS forwarding or your name server will not be the one making the final query. HTH, Barry From rvandolson at esri.com Fri Jul 25 13:29:38 2008 From: rvandolson at esri.com (Ray Van Dolson) Date: Fri, 25 Jul 2008 06:29:38 -0700 Subject: BIND Port Randomization In-Reply-To: <002801c8ee59$0280e1c0$483a14c6@large2> References: <002801c8ee59$0280e1c0$483a14c6@large2> Message-ID: <20080725132938.GA12882@esri.com> On Fri, Jul 25, 2008 at 06:19:02AM -0700, Ryan Sharpe wrote: > In response to the Errta RHSA-2008:0533 I have installed the updated ISC > Bind packages from Red Hat as well as updated the selinux targeted policy. > However when I test the server using http://www.doxpara.com/ it still > shows up as being vulnerable to DNS cache poisoning. > > Before this I had SELinux completely disabled, so I though I may need to > turn it on. I have since set it to permissive mode and rebooted, but still > the DNS source ports aren't randomizing. So again I changed the mode to > enforcing, but still when I run the test it shows that I am vulnerable. > What am I missing, is there a BIND directive I need? Is your DNS server sitting behind a NAT? Ray From rsharpe at largnet.on.ca Fri Jul 25 13:53:41 2008 From: rsharpe at largnet.on.ca (Ryan Sharpe) Date: Fri, 25 Jul 2008 09:53:41 -0400 (EDT) Subject: BIND Port Randomization In-Reply-To: References: <002801c8ee59$0280e1c0$483a14c6@large2> Message-ID: <003001c8ee5d$d9acaa40$483a14c6@large2> Thanks Barry! The problem was indeed the query-source. Ryan Sharpe, CCNA Technical Analyst LARG*net (519) 661-2111 x 86356 support pager: (519) 690-3216 -----Original Message----- From: redhat-sysadmin-list-bounces at redhat.com [mailto:redhat-sysadmin-list-bounces at redhat.com] On Behalf Of Barry Brimer Sent: Friday, July 25, 2008 09:28 AM To: redhat-sysadmin-list at redhat.com Subject: Re: BIND Port Randomization > In response to the Errta RHSA-2008:0533 I have installed the updated ISC > Bind packages from Red Hat as well as updated the selinux targeted policy. > However when I test the server using http://www.doxpara.com/ it still > shows up as being vulnerable to DNS cache poisoning. > > Before this I had SELinux completely disabled, so I though I may need to > turn it on. I have since set it to permissive mode and rebooted, but still > the DNS source ports aren't randomizing. So again I changed the mode to > enforcing, but still when I run the test it shows that I am vulnerable. > What am I missing, is there a BIND directive I need? The latest BIND does work with the latest SELinux packages .. in fact on RHEL 5 you *NEED* the latest SELinux packages or named is not allowed to use random ports. Make sure there is not a line in your named.conf that says "query-source address * port 53" .. that is basically instructing your named to only use port 53. If you are behind a NAT device, it may reorder the source ports being used when going through the NAT .. which is a bigger problem to fix and dependant upon your NAT vendor. Make sure that you are not doing DNS forwarding or your name server will not be the one making the final query. HTH, Barry -- redhat-sysadmin-list mailing list redhat-sysadmin-list at redhat.com https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list From rsharpe at largnet.on.ca Fri Jul 25 13:53:41 2008 From: rsharpe at largnet.on.ca (Ryan Sharpe) Date: Fri, 25 Jul 2008 09:53:41 -0400 (EDT) Subject: BIND Port Randomization In-Reply-To: References: <002801c8ee59$0280e1c0$483a14c6@large2> Message-ID: <003001c8ee5d$d9acaa40$483a14c6@large2> Thanks Barry! The problem was indeed the query-source. Ryan Sharpe, CCNA Technical Analyst LARG*net (519) 661-2111 x 86356 support pager: (519) 690-3216 -----Original Message----- From: redhat-sysadmin-list-bounces at redhat.com [mailto:redhat-sysadmin-list-bounces at redhat.com] On Behalf Of Barry Brimer Sent: Friday, July 25, 2008 09:28 AM To: redhat-sysadmin-list at redhat.com Subject: Re: BIND Port Randomization > In response to the Errta RHSA-2008:0533 I have installed the updated ISC > Bind packages from Red Hat as well as updated the selinux targeted policy. > However when I test the server using http://www.doxpara.com/ it still > shows up as being vulnerable to DNS cache poisoning. > > Before this I had SELinux completely disabled, so I though I may need to > turn it on. I have since set it to permissive mode and rebooted, but still > the DNS source ports aren't randomizing. So again I changed the mode to > enforcing, but still when I run the test it shows that I am vulnerable. > What am I missing, is there a BIND directive I need? The latest BIND does work with the latest SELinux packages .. in fact on RHEL 5 you *NEED* the latest SELinux packages or named is not allowed to use random ports. Make sure there is not a line in your named.conf that says "query-source address * port 53" .. that is basically instructing your named to only use port 53. If you are behind a NAT device, it may reorder the source ports being used when going through the NAT .. which is a bigger problem to fix and dependant upon your NAT vendor. Make sure that you are not doing DNS forwarding or your name server will not be the one making the final query. HTH, Barry -- redhat-sysadmin-list mailing list redhat-sysadmin-list at redhat.com https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list From Tim.Mooney at ndsu.edu Tue Jul 29 22:52:24 2008 From: Tim.Mooney at ndsu.edu (Tim Mooney) Date: Tue, 29 Jul 2008 17:52:24 -0500 (CDT) Subject: finding storage at boot on luns other than 0 (sparse luns) Message-ID: We have a variant of the SCSI "sparse lun" problem, and I would like some advice on what the recommended method is to work around it. Searching for "sparse lun" and various other keywords related to it turns up lots of hits in the search engines, but most of them are old and none of them seem to work reliably with recent RHEL. The systems in question are RHEL 5.2, completely up to date. The boxes get some storage via a pair of connections through a dual-port QLx2xxx FC card. The problem is that the storage appears on a lun other than 0 (there's nothing on lun 0): $cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: SEAGATE Model: ST336807LC Rev: 0C01 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: SEAGATE Model: ST336807LC Rev: 0C01 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: ESG-SHV Model: SCA HSBP M29 Rev: 1.06 Type: Processor ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 00 Lun: 04 Vendor: MAYASTOR Model: lvm(58,3) Rev: 0.9 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi3 Channel: 00 Id: 00 Lun: 04 Vendor: MAYASTOR Model: lvm(58,4) Rev: 0.9 Type: Direct-Access ANSI SCSI revision: 03 The storage on scsi2, target 0, lun 4 and scsi3, target 0, lun 4 are part of a md RAID1 mirror pair. That md RAID1 device fails to assemble on system startup, because the system never detects the two volumes that make up the md device. If we manually echo the appropriate value into the /sys/class/scsi_host/hostN/scan file, then the device shows up. If we do it for both devices, we can then assemble the array manually. The question is, how do we get this to happen automatically during the startup process, and early enough so that the devices are available for md startup? We tried adding options scsi_mod default_dev_flags=0x240 to /etc/modprobe.conf and then rebuilding the initrd, where 0x200 = Scan for large LUNs 0x040 = Handle sparse LUN numbering That does indeed force the system to scan for sparse luns, but the problem is that it now scans for lun numbers > 16,384, and the fibre targets that are providing this storage don't react well to that. In this case we don't need the system to scan past lun 7, but we have other systems with this exact same problem where the storage is on e.g. lun 11, so we need a solution that doesn't stop probing sparse luns at lun 7. I also tried leaving out the 0x200 but instead specifying max_luns, so we could control what the highest lun number was that the system scanned for, but I wasn't able to make that work in coordination with default_dev_flags=0x040 in /etc/modprobe.conf. Am I on the right track, or is there some other supported method with RHEL 5.x to get the system to detect sparse luns at boot time, early enough to use those devices as part of LVM or md? Thanks, Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 From herta.vandeneynde at gmail.com Wed Jul 30 06:51:28 2008 From: herta.vandeneynde at gmail.com (Herta Van den Eynde) Date: Wed, 30 Jul 2008 08:51:28 +0200 Subject: finding storage at boot on luns other than 0 (sparse luns) In-Reply-To: References: Message-ID: 2008/7/30 Tim Mooney : > > We have a variant of the SCSI "sparse lun" problem, and I would like some > advice on what the recommended method is to work around it. Searching > for "sparse lun" and various other keywords related to it turns up lots > of hits in the search engines, but most of them are old and none of them > seem to work reliably with recent RHEL. > > The systems in question are RHEL 5.2, completely up to date. The boxes > get some storage via a pair of connections through a dual-port QLx2xxx > FC card. The problem is that the storage appears on a lun other than 0 > (there's nothing on lun 0): > > $cat /proc/scsi/scsi Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: SEAGATE Model: ST336807LC Rev: 0C01 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi0 Channel: 00 Id: 03 Lun: 00 > Vendor: SEAGATE Model: ST336807LC Rev: 0C01 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi0 Channel: 00 Id: 06 Lun: 00 > Vendor: ESG-SHV Model: SCA HSBP M29 Rev: 1.06 > Type: Processor ANSI SCSI revision: 02 > Host: scsi2 Channel: 00 Id: 00 Lun: 04 > Vendor: MAYASTOR Model: lvm(58,3) Rev: 0.9 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi3 Channel: 00 Id: 00 Lun: 04 > Vendor: MAYASTOR Model: lvm(58,4) Rev: 0.9 > Type: Direct-Access ANSI SCSI revision: 03 > > > The storage on scsi2, target 0, lun 4 and scsi3, target 0, lun 4 are part > of a md RAID1 mirror pair. That md RAID1 device fails to assemble on system > startup, because the system never detects the two volumes that make up the > md device. > > If we manually echo the appropriate value into the > > /sys/class/scsi_host/hostN/scan > > file, then the device shows up. If we do it for both devices, we can then > assemble the array manually. > > The question is, how do we get this to happen automatically during the > startup process, and early enough so that the devices are available for > md startup? > > We tried adding > > options scsi_mod default_dev_flags=0x240 > > to /etc/modprobe.conf and then rebuilding the initrd, where > > 0x200 = Scan for large LUNs > 0x040 = Handle sparse LUN numbering > > That does indeed force the system to scan for sparse luns, but the > problem is that it now scans for lun numbers > 16,384, and the fibre > targets that are providing this storage don't react well to that. In > this case we don't need the system to scan past lun 7, but we have other > systems with this exact same problem where the storage is on e.g. lun 11, > so we need a solution that doesn't stop probing sparse luns at lun 7. > > I also tried leaving out the 0x200 but instead specifying max_luns, so > we could control what the highest lun number was that the system scanned > for, but I wasn't able to make that work in coordination with > default_dev_flags=0x040 in /etc/modprobe.conf. > > Am I on the right track, or is there some other supported method with > RHEL 5.x to get the system to detect sparse luns at boot time, early > enough to use those devices as part of LVM or md? > > Thanks, > > Tim > -- > Tim Mooney Tim.Mooney at ndsu.edu > Enterprise Computing & Infrastructure 701-231-1076 (Voice) > Room 242-J6, IACC Building 701-231-8541 (Fax) > North Dakota State University, Fargo, ND 58105-5164 > Hi Tim, Last time I had a system like this, I simply edited the system startup and shutdown scripts to assemble the array at the proper time. The attached .pdf has the instructions for a Red Hat 4 system. You'll probably have to modify some details, but it should be easy to figure out what. Hope this helps. Kind regards, Herta -- "Life on Earth may be expensive, but it comes with a free ride around the Sun." -------------- next part -------------- A non-text attachment was scrubbed... Name: md.pdf Type: application/pdf Size: 75002 bytes Desc: not available URL: From Tim.Mooney at ndsu.edu Wed Jul 30 19:17:53 2008 From: Tim.Mooney at ndsu.edu (Tim Mooney) Date: Wed, 30 Jul 2008 14:17:53 -0500 (CDT) Subject: finding storage at boot on luns other than 0 (sparse luns) In-Reply-To: References: Message-ID: In regard to: Re: finding storage at boot on luns other than 0 (sparse...: >> We tried adding >> >> options scsi_mod default_dev_flags=0x240 >> >> to /etc/modprobe.conf and then rebuilding the initrd, where >> >> 0x200 = Scan for large LUNs >> 0x040 = Handle sparse LUN numbering >> >> That does indeed force the system to scan for sparse luns, but the >> problem is that it now scans for lun numbers > 16,384, and the fibre >> targets that are providing this storage don't react well to that. In >> this case we don't need the system to scan past lun 7, but we have other >> systems with this exact same problem where the storage is on e.g. lun 11, >> so we need a solution that doesn't stop probing sparse luns at lun 7. >> >> I also tried leaving out the 0x200 but instead specifying max_luns, so >> we could control what the highest lun number was that the system scanned >> for, but I wasn't able to make that work in coordination with >> default_dev_flags=0x040 in /etc/modprobe.conf. >> >> Am I on the right track, or is there some other supported method with >> RHEL 5.x to get the system to detect sparse luns at boot time, early >> enough to use those devices as part of LVM or md? > > Last time I had a system like this, I simply edited the system startup > and shutdown scripts to assemble the array at the proper time. The > attached .pdf has the instructions for a Red Hat 4 system. You'll > probably have to modify some details, but it should be easy to figure > out what. Thanks Herta. That's more or less the "temporary solution" we have in place right now. We just added the appropriate "echo" commands redirected into the appropriate /sys file into the /etc/rc.d/rc.sysinit script, but that's a hack. We have to have the initscripts RPM on the yum skip list, otherwise our customizations will be clobbered by an initscripts update through Red Hat Network and the next reboot will fail until we reimplement them. I just figured there had to be a better, cleaner solution to do what we needed to do. Thanks, Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164