[CentOS] Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
After getting a reasonably configured NFS4 setup working on my Scientific Linux server, I spent a majority of my evening trying to do the same with my Centos 5 box, with fruitless results. Most attempts to mount that server returns the following message: [root@sl01 log]# mount -t nfs4 192.168.15.200:/opt/company_data /mnt mount.nfs4: Operation not permitted As nearest as I can tell, I was able to setup the ports correctly in /etc/sysconfig/nfs [root@centos sysconfig]# grep -v \# nfs RQUOTAD_PORT=875 LOCKD_TCPPORT=32803 LOCKD_UDPPORT=32769 MOUNTD_PORT=892 STATD_PORT=662 As well as my /etc/services file: # Local services rquotad 875/tcp lockd32803/tcp lockd32769/tcp mountd 892/tcp statd 662/tcp rquotad 875/udp lockd 32803/udp lockd 32769/udp mountd 892/udp statd 662/udp [root@centos sy rpcinfo -p seems fine (although I understand that is not relevent with nfs4) [root@centos sysconfig]# rpcinfo -p program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000241 udp662 status 1000241 tcp662 status 1000111 udp875 rquotad 1000112 udp875 rquotad 1000111 tcp875 rquotad 1000112 tcp875 rquotad 132 udp 2049 nfs 133 udp 2049 nfs 134 udp 2049 nfs 1000211 udp 32769 nlockmgr 1000213 udp 32769 nlockmgr 1000214 udp 32769 nlockmgr 1000211 tcp 32803 nlockmgr 1000213 tcp 32803 nlockmgr 1000214 tcp 32803 nlockmgr 132 tcp 2049 nfs 133 tcp 2049 nfs 134 tcp 2049 nfs 151 udp892 mountd 151 tcp892 mountd 152 udp892 mountd 152 tcp892 mountd 153 udp892 mountd 153 tcp892 mountd And services are running: [root@centos sysconfig]# service nfs status rpc.mountd (pid 6321) is running... nfsd (pid 6318 6317 6316 6315 6314 6313 6312 6311) is running... rpc.rquotad (pid 6306) is running... [root@centos sysconfig]# service nfslock status rpc.statd (pid 6248) is running... [root@centos sysconfig]# service portmap status portmap (pid 6210) is running... And firewall is open both ways: [root@centos sysconfig]# iptables -n -L | grep -E '(2049|111|32759|32803|662|875|892)' ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:111 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:2049 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:2049 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:875 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:875 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:875 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:892 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:662 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:32803 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:32803 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:662 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:892 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:111 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:111 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:111 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:2049 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:2049 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:32803 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:32803 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:662 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:662 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:892 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:875 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:875 I am about to mount via NFS3, so that part I know works. Is there a known problem with NFS4 on Centos (or Red Hat) 5? Or am I missing something someplace? - Rilindo ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
I can try to play around with the idmapd.conf and set the fsid=0 option. What bugs me, though, is that neither option is enabled on the SL6/RHES6 server and I am able to mount via nfs4: [root@centos sysconfig]# nfsstat Server rpc stats: calls badcalls badauthbadclntxdrcall 1540 0 0 0 Server nfs v3: null getattr setattr lookup access readlink 28 36% 27 35% 0 0% 0 0% 0 0% 0 0% read writecreate mkdirsymlink mknod 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% remove rmdirrename link readdir readdirplus 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% fsstat fsinfo pathconf commit 3 3% 16 20% 3 3% 0 0% Server nfs v4: null compound 32 45% 38 54% Server nfs v4 operations: op0-unused op1-unused op2-future access closecommit 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% create delegpurge delegreturn getattr getfhlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% lock locktlockulookup lookup_root nverify 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% open openattr open_confopen_dgrdputfhputpubfh 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% putrootfhread readdir readlink remove rename 35 92% 0 0% 0 0% 0 0% 0 0% 0 0% renewrestorefhsavefh secinfo setattr setcltid 1 2% 0 0% 0 0% 0 0% 0 0% 1 2% setcltidconf verify writerellockowner 1 2% 0 0% 0 0% 0 0% Client rpc stats: calls retransauthrefrsh 38 0 0 Client nfs v4: null read writecommit open open_conf 0 0% 0 0% 0 0% 0 0% 1 2% 1 2% open_noatopen_dgrdclosesetattr fsinfo renew 0 0% 0 0% 1 2% 1 2% 411% 0 0% setclntidconfirm lock locktlockuaccess 1 2% 1 2% 0 0% 0 0% 0 0% 2 5% getattr lookup lookup_root remove rename link 719% 513% 2 5% 0 0% 0 0% 0 0% symlink create pathconf statfs readlink readdir 0 0% 0 0% 0 0% 2 5% 0 0% 2 5% server_caps delegreturn 616% 0 root@centos sysconfig]# cat /etc/mtab /dev/sda6 / ext3 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/sda8 /home ext3 rw 0 0 /dev/sda5 /usr ext3 rw 0 0 /dev/sda3 /opt ext3 rw 0 0 /dev/sda2 /var ext3 rw 0 0 /dev/sda1 /boot ext3 rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 nfsd /proc/fs/nfsd nfsd rw 0 0 /opt/company_data /exports/company_data none rw,bind 0 0 192.168.15.100:/opt/company_data /mnt nfs4 rw,addr=192.168.15.100 0 0 (Of course, it could be that SL6 did things a little differently with their distro's implementation of NFS4, but I doubt it). On May 30, 2011, at 10:29 PM, Tom H wrote: > On Mon, May 30, 2011 at 9:31 PM, RILINDO FOSTER wrote: >> >> After getting a reasonably configured NFS4 setup working on my Scientific >> Linux >> server, I spent a majority of my evening trying to do the same with my >> Centos 5 >> box, with fruitless results. Most attempts to mount that server returns the >> following >> message: >> >> [root@sl01 log]# mount -t nfs4 192.168.15.200:/opt/company_data /mnt >> mount.nfs4: Operation not permitted >> >> As nearest as I can tell, I was able to setup the ports correctly in >> /etc/sysconfig/nfs >> >> [root@centos sysconfig]# grep -v \# nfs >> RQUOTAD_PORT=875 >> LOCKD_TCPPORT=32803 >> LOCKD_UDPPORT=32769 >> MOUNTD_PORT=892 >> STATD_PORT=662 >> >> [root@centos sysconfig]# rpcinfo -p >> program vers proto port >>102 tcp111 portmapper >>102 udp111 portmapper >>1000241 udp662 status >>1000241 tcp662 status >>1000111 udp875 rquotad >>1000112 udp875 rquotad
Re: [CentOS] Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
It is actually commented out in SL6. On Jun 2, 2011, at 11:56 AM, Tom H wrote: > On Mon, May 30, 2011 at 10:53 PM, RILINDO FOSTER wrote: >> On May 30, 2011, at 10:29 PM, Tom H wrote: >>> >>> Are the values of "Domain" in "/etc/idmapd.conf" the same on the >>> client and the server? >>> >>> FYI: For nfsv4, there's no need to have any ports other than 111 and 2049. >>> >>> (Are you using "fsid=0" as an option?) >> >> I can try to play around with the idmapd.conf and set the fsid=0 option. What >> bugs me, though, is that neither option is enabled on the SL6/RHES6 server >> and I am able to mount via nfs4: > > I was asking about "Domain" in "idmapd.conf" because there might be a > difference between CentOS 5 and SL 6. > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
I did that. It didn't help. :( On Jun 2, 2011, at 6:07 PM, Tom H wrote: > On Thu, Jun 2, 2011 at 2:01 PM, RILINDO FOSTER wrote: >> On Jun 2, 2011, at 11:56 AM, Tom H wrote: >>> >>> I was asking about "Domain" in "idmapd.conf" because there might be a >>> difference between CentOS 5 and SL 6. >> >> It is actually commented out in SL6. > > There you go. Comment it out on CentOS and restart idmapd - and cross > your fingers. > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
Here you go. Nothing too fancy: [root@centos ~]# cat /etc/exports /home *(ro,sync) /opt/company_data *(rw,sync) On Jun 2, 2011, at 2:07 PM, Louis Lagendijk wrote: > On Thu, 2011-06-02 at 14:01 -0400, RILINDO FOSTER wrote: >> It is actually commented out in SL6. >> >> >> On Jun 2, 2011, at 11:56 AM, Tom H wrote: >> >>> On Mon, May 30, 2011 at 10:53 PM, RILINDO FOSTER wrote: >>>> On May 30, 2011, at 10:29 PM, Tom H wrote: >>>>> >>>>> Are the values of "Domain" in "/etc/idmapd.conf" the same on the >>>>> client and the server? >>>>> >>>>> FYI: For nfsv4, there's no need to have any ports other than 111 and 2049. >>>>> >>>>> (Are you using "fsid=0" as an option?) >>>> > Can you please show your /etc/exports? I remember that in Fedora some > changes were made which probably included in RHEL6 as well that made > fsid superfluous. Here is mine in case it helps you: > /export gss/krb5(fsid=0,sync,insecure,no_subtree_check,no_root_squash) > /export/home1 > gss/krb5(rw,nohide,sync,insecure,no_subtree_check,no_root_squash) > /export/home2 > gss/krb5(rw,nohide,sync,insecure,no_subtree_check,no_root_squash) > > Louis > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] SOLVED (was Re: Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
Okay, it took a few minutes, but I figure it out. Seems that Scientific Linux eems to regress a bit in this area. With Centos, you need to bind like so: /home/share /exports/share nonebind0 0 /home/vhosts/exports/vhosts nonebind0 0 And then specify the options (including fsid0): in /etc/exports /exports*(rw,fsid=0,insecure,no_subtree_check,sync,no_root_squash) /exports/vhosts *(rw,fsid=0,insecure,no_subtree_check,sync,no_root_squash) /exports/share *(rw,fsid=0,insecure,no_subtree_check,sync,no_root_squash) [root@centos home]# In order for clients to mount via NFS4 (with all the usual stuff about specifying in the ports in /etc/sysconfig/nfs) in thisfmat : mount -t nfs4 192.168.15.200:/ /mnt Which is apparently the correct way of mount via NFS HOWEVER, in Scientific Linux, you can get way with a) not binding the directories and b) go back to this format: /home/exports *(ro,sync) /opt*(ro,sync) And still be able to mount: mount -t nfs4 192.168.15.100:/opt /mnt I have to double check the mounts to confirm that I am mount via NFS4. Centos box (mounting SL box via NFS4): 192.168.15.100:/opt /mnt nfs4 rw,addr=192.168.15.100 0 SL Box (mounting Centos box via NFS4): 192.168.15.200:/ /mnt nfs4 rw,addr=192.168.15.200,clientaddr=192.168.15.100 0 0 Huh. Thanks a lot for the pointers, guys. It has been interesting. :) On Jun 2, 2011, at 8:50 PM, RILINDO FOSTER wrote: > Here you go. Nothing too fancy: > > [root@centos ~]# cat /etc/exports > /home *(ro,sync) > /opt/company_data *(rw,sync) > > > > On Jun 2, 2011, at 2:07 PM, Louis Lagendijk wrote: > >> On Thu, 2011-06-02 at 14:01 -0400, RILINDO FOSTER wrote: >>> It is actually commented out in SL6. >>> >>> >>> On Jun 2, 2011, at 11:56 AM, Tom H wrote: >>> >>>> On Mon, May 30, 2011 at 10:53 PM, RILINDO FOSTER wrote: >>>>> On May 30, 2011, at 10:29 PM, Tom H wrote: >>>>>> >>>>>> Are the values of "Domain" in "/etc/idmapd.conf" the same on the >>>>>> client and the server? >>>>>> >>>>>> FYI: For nfsv4, there's no need to have any ports other than 111 and >>>>>> 2049. >>>>>> >>>>>> (Are you using "fsid=0" as an option?) >>>>> >> Can you please show your /etc/exports? I remember that in Fedora some >> changes were made which probably included in RHEL6 as well that made >> fsid superfluous. Here is mine in case it helps you: >> /export gss/krb5(fsid=0,sync,insecure,no_subtree_check,no_root_squash) >> /export/home1 >> gss/krb5(rw,nohide,sync,insecure,no_subtree_check,no_root_squash) >> /export/home2 >> gss/krb5(rw,nohide,sync,insecure,no_subtree_check,no_root_squash) >> >> Louis >> >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SOLVED (was Re: Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
On Jun 4, 2011, at 7:52 AM, Louis Lagendijk wrote: > On Fri, 2011-06-03 at 23:49 -0400, RILINDO FOSTER wrote: >> Okay, it took a few minutes, but I figure it out. Seems that Scientific >> Linux eems to regress a bit in this area. >> >> With Centos, you need to bind like so: >> >> /home/share /exports/share nonebind0 0 >> /home/vhosts /exports/vhosts nonebind0 0 >> >> And then specify the options (including fsid0): >> >> in /etc/exports >> >> /exports *(rw,fsid=0,insecure,no_subtree_check,sync,no_root_squash) >> /exports/vhosts >> *(rw,fsid=0,insecure,no_subtree_check,sync,no_root_squash) >> /exports/share >> *(rw,fsid=0,insecure,no_subtree_check,sync,no_root_squash) >> [root@centos home]# > This is not right AFAIK, fsid should be specified ONLY on the export > root. Search for fsid in "man expports" > Louis > Ah, okay. I was going based on this: http://www.brennan.id.au/19-Network_File_System.html#nfs4 but I didn't pay close attention to where fsid is only specified once fixed. Thanks for that correction! - Rilindo ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SOLVED (was Re: Unable to mount Centos 5.6 Server via nfs4 - Operation Not Permitted - MADNESS!
On Jun 4, 2011, at 4:27 AM, Ljubomir Ljubojevic wrote: > RILINDO FOSTER wrote: >> Okay, it took a few minutes, but I figure it out. Seems that Scientific >> Linux eems to regress a bit in this area. >> SL Box (mounting Centos box via NFS4): >> >> 192.168.15.200:/ /mnt nfs4 rw,addr=192.168.15.200,clientaddr=192.168.15.100 >> 0 0 >> >> Huh. >> >> Thanks a lot for the pointers, guys. It has been interesting. :) >> >> On Jun 2, 2011, at 8:50 PM, RILINDO FOSTER wrote: >> >>> Here you go. Nothing too fancy: >>> >>> [root@centos ~]# cat /etc/exports >>> /home *(ro,sync) >>> /opt/company_data *(rw,sync) >>> > > If I am not mistaking, difference might be between 5.x and 6.x, not > distro oriented. Not binding and having DNS/hostname issues is nice and > is progress. If I understand this correctly, the steps required to mount a NFS4 export is supposed to include binding the directories, right? In that case, SL 6.x (and maybe Red Hat 6.x) is breaking convention here. Make it easier for old-school admins like me, though. :) - Rilindo ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ssh after failing fsck?
You'll have to hope that ssh does not reside on the same file system that has errors. You probably better off getting a remote access card or a terminal that allows you to console into the server - sort of like this: http://en.wikipedia.org/wiki/Dell_DRAC On Jul 15, 2011, at 5:34 PM, Les Mikesell wrote: > Is there any way to configure things so sshd starts even if a filesystem > mentioned in fstab has errors that fail the automatic fsck at boot? Due > to some power issues I'm sitting at work for a long fsck to complete - > or more likely fail, so I can run it manually like it will tell me on > the console. I'd much rather ssh in from home and do that later... > > -- > Les Mikesell >lesmikes...@gmail.com > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos6 - Logwatch not mailing on 64bit
Well, can we verify whether the sent mail generated in the /var/log/mail.log? Also, (assuming that you are running Postfix), I assume that the configuration are identical on both 32-bit and 64-bit systems, right? On Aug 21, 2011, at 3:23 PM, david wrote: > Folks > > Logwatch is doing its thing properly on my 32-bit servers, delivering > the report by mail to my root account once a day sometime around 3:30am. > > On the 64-bit systems, no mail is occurring. From the "cron" log on > a 64-bit system, there are lines like: > > cron-20110821:Aug 21 03:36:23 XXX run-parts(/etc/cron.daily)[9727]: > finished 0logwatch > (where "XXX" stands for the server name) > > but no report is sent. > > If I run logtwatch manually, by simply typing > logwatch > as root, I get the mail. > > Is this a known issue? Is there some information I could supply that > would help identify the reason? > To the best of my knowledge, I made no changes to the logwatch configuration. > > Thanks > > David Kurn > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos6 - Logwatch not mailing on 64bit
On Aug 21, 2011, at 3:56 PM, David wrote: > At 12:32 PM 8/21/2011, you wrote: >> Well, can we verify whether the sent mail generated in the >> /var/log/mail.log? Also, (assuming that you are running Postfix), I >> assume that the configuration are identical on both 32-bit and >> 64-bit systems, right? >> >> On Aug 21, 2011, at 3:23 PM, david wrote: >> >>> Folks >>> >>> Logwatch is doing its thing properly on my 32-bit servers, delivering >>> the report by mail to my root account once a day sometime around 3:30am. >>> >>> On the 64-bit systems, no mail is occurring. From the "cron" log on >>> a 64-bit system, there are lines like: >>> >>> cron-20110821:Aug 21 03:36:23 XXX run-parts(/etc/cron.daily)[9727]: >>> finished 0logwatch >>> (where "XXX" stands for the server name) >>> >>> but no report is sent. >>> >>> If I run logtwatch manually, by simply typing >>> logwatch >>> as root, I get the mail. >>> >>> Is this a known issue? Is there some information I could supply that >>> would help identify the reason? >>> To the best of my knowledge, I made no changes to the logwatch >> configuration. >>> >>> Thanks >>> >>> David Kurn >>> > > > Rilindo: > I performed as root > cd /var/log > grep -ri logw * > > and only the "cron-" messages showed up. I am using Sendmail and > dovecot, and the sendmail is configured to relay all mail to my > (local) mail server as a "smart relay" > > [converting to posting responses at the bottom] > > David It sounds like it is set not to send email. If you haven't make any changes, it would be weird, since it defaults to send email, but you may want to verify this file: /usr/share/logwatch/default.conf/logwatch.conf And see if this part of the file is commented out or at least set to yes: # By default the cron daemon generates daily logwatch report # if you want to switch it off uncomment DailyReport tag. # The implicit value is Yes # # DailyReport = No ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6.0: panic installing i386 on old Acer Desktop
No ideas yet, but let me ask this: if you boot into rescue mode mode with a CentOS 6 disk, what happens if you were modify partitions and format the file systems within the shell? It would be interesting to see if you were to get a kernel panic at that point or not. - Rilindo Foster http://monzell.com http://www.linkedin.com/pub/rilindo-foster/2/b32/43b On Oct 16, 2011, at 2:46 PM, "William L. Maltby" wrote: > > On Sun, 2011-10-16 at 14:28 -0400, William L. Maltby wrote: >> > >> I tried, based on *old* memories, adding kernel arguments of noapic and >> nolapic (IIRC). Still no joy. >> > > Amazing what brainstorms hit after you click "send". Unfortunately, the > thoughts didn't help. > > I tried again using the kernel parameters from the CentOS 4.8 grub > kernel parameters that still work. > > ide0=ata66 ide1=ata66 hdc=ide-cd lapic > > AFAICT, same results. > > TIA, > Bill > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 6.1 .iso size?
Have you thought about installing it from the network? Just burn a net install.iso, boot off from there, and at the network install prompt, enter path one of the mirrors. After that, you are set. On Dec 3, 2011, at 3:20 PM, Beartooth wrote: > > I haven't managed to get hold of any DVD-R media, and the machine > I particularly want to install on seems not to be able to see double- > sided (which I do have). (It's not exactly a new PC.) > > So I can't get 6.0 onto it in the usual way. But I can wait till > 6.1 comes out; it is possible to predict yet whether it will squeeze in > under the DVD+R limit? > > -- > Beartooth Staffwright, Not Quite Clueless Power User > I have precious (very precious!) little idea where up is. > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 6.1 .iso size?
Here is one for the net install: http://www.gtlib.gatech.edu/pub/centos/6.0/isos/x86_64/CentOS-6.0-x86_64-netinstall.iso And for the live media: http://www.gtlib.gatech.edu/pub/centos/6.0/isos/x86_64/CentOS-6.0-x86_64-LiveCD.iso Alternatively, there is always bit torrent. On Dec 3, 2011, at 5:11 PM, Beartooth wrote: > On Sat, 03 Dec 2011 22:29:23 +0100, Ljubomir Ljubojevic wrote: > >>> copy the ISO contents to a local http server, point at that. > >> There is also option to install from LiveDVD, and then just install the >> missing packages. > > I don't have that kind of access to any http server. But mighty > few of the North American mirrors have either live media or netinstall > ones, unless they call them something I don't recognize, or list them in > places I don't think to look. Anyone have a direct URL handy? > > -- > Beartooth Staffwright, Not Quite Clueless Power User > I have precious (very precious!) little idea where up is. > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 6.1 .iso size?
http://www.gtlib.gatech.edu/pub/centos/6.0/isos/i386/CentOS-6.0-i386-LiveDVD.iso http://www.gtlib.gatech.edu/pub/centos/6.0/isos/i386/CentOS-6.0-i386-netinstall.iso On Dec 4, 2011, at 5:52 AM, Phil Dobbin wrote: > On 3/12/11 22:13, "RILINDO FOSTER" wrote: > >> Here is one for the net install: >> >> http://www.gtlib.gatech.edu/pub/centos/6.0/isos/x86_64/CentOS-6.0-x86_64-netin >> stall.iso >> >> And for the live media: >> >> http://www.gtlib.gatech.edu/pub/centos/6.0/isos/x86_64/CentOS-6.0-x86_64-LiveC >> D.iso > > Has anybody got a link for a i386 LiveCD for 5.7? I've looked everywhere but > to no avail. > > Cheers, > >Phil... > > -- > Nothing to see here... move along, move along > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Booting C 6.0 from C 5.7
On Dec 4, 2011, at 11:40 PM, Always Learning wrote: > > I installed C 6.0 in an empty partition. It functioned. > > Despite using the usually successful methods of booting into another > operating system from C 5.7, I can't get into C 6.0 > > Tried:- > > title C6-0 (2.6.32-71.el6.x86_64) > > rootnoverify (hd0,6) > chainloader +1 > > and > > root (hd0,6) > kernel /boot/vmlinuz-2.6.32-71.el6.x86_64 ro > root=UUID=67c62872-0c69-451c-8412-3c218c0d2cb0 rd_NO_LUKS rd_NO_LVM > rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 > KEYBOARDTYPE=pc KEYTABLE=uk > initrd /boot/initramfs-2.6.32-71.el6.x86_64.img > > > My default works:- > > title CentOS 5.7 #6 (2.6.18-274.7.1.el5) > root (hd0,0) > kernel /boot/vmlinuz-2.6.18-274.7.1.el5 ro root=LABEL=d6sys > ramdisk_size=60 > initrd /boot/initrd-2.6.18-274.7.1.el5.img > > and so does Ubuntu > > title Ubuntu 11.04 (chain) (2.6.38-8) > rootnoverify (hd0,4) > chainloader +1 > > but Centos 6.0 fails. > > Advice appreciated. > > What does it say when you attempt to boot to it? Did it fail on stage 1, 1.5 or 2? - Rilindo ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Booting C 6.0 from C 5.7
Somebody could correct me, but if the installed Centos install is on a ext4 file system, then the installed version of grub needs to support it. Which version of grub are you running and from which distro? - Rilindo Foster http://monzell.com http://www.linkedin.com/pub/rilindo-foster/2/b32/43b On Dec 4, 2011, at 11:53 PM, Always Learning wrote: >> Despite using the usually successful methods of booting into another >> operating system from C 5.7, I can't get into C 6.0 >> >> Tried:- >> >> title C6-0 (2.6.32-71.el6.x86_64) >> >>rootnoverify (hd0,6) >>chainloader +1 >> >> and >> >>root (hd0,6) >>kernel /boot/vmlinuz-2.6.32-71.el6.x86_64 ro >> root=UUID=67c62872-0c69-451c-8412-3c218c0d2cb0 rd_NO_LUKS rd_NO_LVM >> rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 >> KEYBOARDTYPE=pc KEYTABLE=uk >>initrd /boot/initramfs-2.6.32-71.el6.x86_64.img > > > > The GRUB error is:- > > 13 : Invalid or unsupported executable format > > This error is returned if the kernel image being loaded is not > recognized as Multiboot or one of the supported native formats (Linux > zImage or bzImage, FreeBSD, or NetBSD). > > > Bewildered. > > Paul. > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Shutdown KVM guest not working
You can run this: Destroy vmname This is an equivalent to powering off the server. Obviously, this may cause some issues with vm when you start it up again. . . Sent from my iPhone On Dec 14, 2011, at 11:47 AM, "James B. Byrne" wrote: > I am in the middle of a rather confusing situation. At > the moment I am unable to shutdown a KVM guest machine. > Nor am I presently able to open a virt-manager session on > the host. > > I am not exactly sure what has happened but the problem > with the vm guest is that issuing a "virsh shutdown 1" > from the root console has no effect. > > # virsh list > Id Name State > > 1 vmguest01 running > > # virsh shutdown 1 > Doamin 1 is being shutdown > > wait 5 minutes > > # virsh list > Id Name State > > 1 vmguest01 running > > How do I get this stopped? > > I have another problem with virt-manager as well. But I > will leave that for another message. > > -- > *** E-Mail is NOT a SECURE channel *** > James B. Byrnemailto:byrn...@harte-lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what percent of time are there unpatched exploits against default config?
On Dec 27, 2011, at 11:29 PM, Bennett Haselton wrote: > On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < > seben...@weather.admin.niu.edu> wrote: > >> On Tue, 27 Dec 2011, Bennett Haselton wrote: >> >>> Suppose I have a CentOS 5.7 machine running the default Apache with no >>> extra modules enabled, and with the "yum-updatesd" service running to >> pull >>> down and install updates as soon as they become available from the >>> repository. >>> >>> So the machine can still be broken into, if there is an unpatched exploit >>> released in the wild, in the window of time before a patch is released >> for >>> that update. >>> >>> Roughly what percent of the time is there such an unpatched exploit in >> the >>> wild, so that the machine can be hacked by someone keeping up with the >>> exploits? 5%? 50%? 95%? >> >> There's no way to give you an exact number, but let me put it this way: >> >> If you've disable as much as you can (which by default, most stuff is >> disabled, so that's good), and you restart Apache after each update, >> your chances of being broken into are better by things like SSH brute >> force attacks. There's always a chance someone will get in, but when you >> look at the security hole history of Apache, particularly over the past >> few years, there have been numerous CVE's, but workarounds and they aren't >> usually earth-shattering. Very few of them have. The latest version that >> ships with 5.7 is as secure as they come. If it wasn't, most web sites >> on the Internet would be hacked by now, as most run Apache >> > > I was asking because I had a server that did get broken into, despite > having yum-updatesd running and a strong password. He said that even if > you apply all latest updates automatically, there were still windows of > time where an exploit in the wild could be used to break into a machine; in > particular he said: > > "For example, there was a while back ( ~march ) a kernel exploit that > affected CentOS / RHEL. The patch came after 1-2 weeks of the security > announcement. The initial announcement provided a simple work around until > the new version is released." > What was the nature of the break-in, if I may ask? Security is more than just updates and a strong password. - Rilindo Foster http://monzell.com http://www.linkedin.com/pub/rilindo-foster/2/b32/43b ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Jan 1, 2012, at 5:23 PM, Bennett Haselton wrote: > (Sorry, third time -- last one, promise, just giving it a subject line!) > > OK, a second machine hosted at the same hosting company has also apparently > been hacked. Since 2 of out of 3 machines hosted at that company have now > been hacked, but this hasn't happened to any of the other 37 dedicated > servers that I've got hosted at other hosting companies (also CentOS, same > version or almost), this makes me wonder if there's a security breach at > this company, like if they store customers' passwords in a place that's > been hacked. (Of course it could also be that whatever attacker found an > exploit, was just scanning that company's address space for hackable > machines, and didn't happen to scan the address space of the other hosting > companies.) > > So, following people's suggestions, the machine is disconnected and hooked > up to a KVM so I can still examine the files. I've found this file: > -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl > which appears to be a copy of this exploit script: > http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html > Note the last-mod date of October 21. > > No other files on the system were last modified on October 21st. However > there was a security advisory dated October 20th which affected httpd: > http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update > https://rhn.redhat.com/errata/RHSA-2011-1392.html > > and a large number of files on the machine, including lots of files in */ > usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , > have a last-mod date of October 20th. So I assume that these are files > which were updated automatically by yum as a result of the patch that goes > with this advisory -- does that sound right? > > So a couple of questions that I could use some help with: > > 1) The last patch affecting httpd was released on October 20th, and the > earliest evidence I can find of the machine being hacked is a file dated > October 21st. This could be just a coincidence, but could it also suggest > that the patch on October 20th introduced a new exploit, which the attacker > then used to get in on October 21st? >(Another possibility: I think that when yum installs updates, it > doesn't actually restart httpd. So maybe even after the patch was > installed, my old httpd instance kept running and was still vulnerable? As > for why it got hacked the very next day, maybe the attacker looked at the > newly released patch and reverse-engineered it to figure out where the > vulnerabilities were, that the patch fixed?) > > 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 > weeks by default, it looks like any log entries related to how the attacker > would have gotten in on or before October 21st, are gone. (The secure* > logs do show multiple successful logins as "root" within the last 4 weeks, > mostly from IP addresses in Asia, but that's to be expected once the > machine was compromised -- it doesn't help track down how they originally > got in.) Anywhere else that the logs would contain useful data? > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos Do you have SELinux enabled? If not, you might need to turn that on, as that would have prevented that exploit. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
≈On Jan 1, 2012, at 8:24 PM, Bennett Haselton wrote: > On Sun, Jan 1, 2012 at 4:57 PM, Rilindo Foster wrote: > >> >> >> On Jan 1, 2012, at 5:23 PM, Bennett Haselton >> wrote: >> >>> (Sorry, third time -- last one, promise, just giving it a subject line!) >>> >>> OK, a second machine hosted at the same hosting company has also >> apparently >>> been hacked. Since 2 of out of 3 machines hosted at that company have >> now >>> been hacked, but this hasn't happened to any of the other 37 dedicated >>> servers that I've got hosted at other hosting companies (also CentOS, >> same >>> version or almost), this makes me wonder if there's a security breach at >>> this company, like if they store customers' passwords in a place that's >>> been hacked. (Of course it could also be that whatever attacker found an >>> exploit, was just scanning that company's address space for hackable >>> machines, and didn't happen to scan the address space of the other >> hosting >>> companies.) >>> >>> So, following people's suggestions, the machine is disconnected and >> hooked >>> up to a KVM so I can still examine the files. I've found this file: >>> -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl >>> which appears to be a copy of this exploit script: >>> http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html >>> Note the last-mod date of October 21. >>> >>> No other files on the system were last modified on October 21st. However >>> there was a security advisory dated October 20th which affected httpd: >>> >> http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update >>> https://rhn.redhat.com/errata/RHSA-2011-1392.html >>> >>> and a large number of files on the machine, including lots of files in */ >>> usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , >>> have a last-mod date of October 20th. So I assume that these are files >>> which were updated automatically by yum as a result of the patch that >> goes >>> with this advisory -- does that sound right? >>> >>> So a couple of questions that I could use some help with: >>> >>> 1) The last patch affecting httpd was released on October 20th, and the >>> earliest evidence I can find of the machine being hacked is a file dated >>> October 21st. This could be just a coincidence, but could it also >> suggest >>> that the patch on October 20th introduced a new exploit, which the >> attacker >>> then used to get in on October 21st? >>> (Another possibility: I think that when yum installs updates, it >>> doesn't actually restart httpd. So maybe even after the patch was >>> installed, my old httpd instance kept running and was still vulnerable? >> As >>> for why it got hacked the very next day, maybe the attacker looked at the >>> newly released patch and reverse-engineered it to figure out where the >>> vulnerabilities were, that the patch fixed?) >>> >>> 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 >>> weeks by default, it looks like any log entries related to how the >> attacker >>> would have gotten in on or before October 21st, are gone. (The secure* >>> logs do show multiple successful logins as "root" within the last 4 >> weeks, >>> mostly from IP addresses in Asia, but that's to be expected once the >>> machine was compromised -- it doesn't help track down how they originally >>> got in.) Anywhere else that the logs would contain useful data? >>> ___ >>> CentOS mailing list >>> CentOS@centos.org >>> http://lists.centos.org/mailman/listinfo/centos >> >> Do you have SELinux enabled? If not, you might need to turn that on, as >> that would have prevented that exploit. >> >> > > I don't, but I'm not sure what you mean by "that would have prevented that > exploit". How do you know what exploit they used, much less that SELinux > would have prevented it? > > Or are you assuming that my guess was correct that they got in because of a > vulnerability that was opened up by the patch being auto-installed on > 10/20, and that if *that* is the case, that SELinux would have prevented > that? How does that work, how would SELinux have prevented a vulnerability > being opened up by the patch install? The script in question is an exploit from a web board which is apparently designed to pull outside traffic. If you had SELinux, it would put httpd in its own context and by default, it will NOT allow connections from that context to another. You have to enable it with: setsebool -P httpd_can_network_connect on - Rilindo ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Jan 1, 2012, at 8:50 PM, Bennett Haselton wrote: > On Sun, Jan 1, 2012 at 5:33 PM, RILINDO FOSTER wrote: > >> ≈On Jan 1, 2012, at 8:24 PM, Bennett Haselton wrote: >> >>> On Sun, Jan 1, 2012 at 4:57 PM, Rilindo Foster wrote: >>> >>>> >>>> >>>> On Jan 1, 2012, at 5:23 PM, Bennett Haselton >>>> wrote: >>>> >>>>> (Sorry, third time -- last one, promise, just giving it a subject >> line!) >>>>> >>>>> OK, a second machine hosted at the same hosting company has also >>>> apparently >>>>> been hacked. Since 2 of out of 3 machines hosted at that company have >>>> now >>>>> been hacked, but this hasn't happened to any of the other 37 dedicated >>>>> servers that I've got hosted at other hosting companies (also CentOS, >>>> same >>>>> version or almost), this makes me wonder if there's a security breach >> at >>>>> this company, like if they store customers' passwords in a place that's >>>>> been hacked. (Of course it could also be that whatever attacker found >> an >>>>> exploit, was just scanning that company's address space for hackable >>>>> machines, and didn't happen to scan the address space of the other >>>> hosting >>>>> companies.) >>>>> >>>>> So, following people's suggestions, the machine is disconnected and >>>> hooked >>>>> up to a KVM so I can still examine the files. I've found this file: >>>>> -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl >>>>> which appears to be a copy of this exploit script: >>>>> http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html >>>>> Note the last-mod date of October 21. >>>>> >>>>> No other files on the system were last modified on October 21st. >> However >>>>> there was a security advisory dated October 20th which affected httpd: >>>>> >>>> >> http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update >>>>> https://rhn.redhat.com/errata/RHSA-2011-1392.html >>>>> >>>>> and a large number of files on the machine, including lots of files in >> */ >>>>> usr/lib64/httpd/modules/* and >> */lib/modules/2.6.18-274.7.1.el5/kernel/* , >>>>> have a last-mod date of October 20th. So I assume that these are files >>>>> which were updated automatically by yum as a result of the patch that >>>> goes >>>>> with this advisory -- does that sound right? >>>>> >>>>> So a couple of questions that I could use some help with: >>>>> >>>>> 1) The last patch affecting httpd was released on October 20th, and the >>>>> earliest evidence I can find of the machine being hacked is a file >> dated >>>>> October 21st. This could be just a coincidence, but could it also >>>> suggest >>>>> that the patch on October 20th introduced a new exploit, which the >>>> attacker >>>>> then used to get in on October 21st? >>>>> (Another possibility: I think that when yum installs updates, it >>>>> doesn't actually restart httpd. So maybe even after the patch was >>>>> installed, my old httpd instance kept running and was still vulnerable? >>>> As >>>>> for why it got hacked the very next day, maybe the attacker looked at >> the >>>>> newly released patch and reverse-engineered it to figure out where the >>>>> vulnerabilities were, that the patch fixed?) >>>>> >>>>> 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back >> 4-5 >>>>> weeks by default, it looks like any log entries related to how the >>>> attacker >>>>> would have gotten in on or before October 21st, are gone. (The secure* >>>>> logs do show multiple successful logins as "root" within the last 4 >>>> weeks, >>>>> mostly from IP addresses in Asia, but that's to be expected once the >>>>> machine was compromised -- it doesn't help track down how they >> originally >>>>> got in.) Anywhere else that the logs would contain useful data? >>>>> ___
Re: [CentOS] an actual hacked machine, in a preserved state
On Jan 2, 2012, at 9:37 PM, Bennett Haselton wrote:
> On 1/2/2012 9:18 AM, Les Mikesell wrote:
>> There have been many, many vulnerabilities that permit local user
>> privilege escalation to root (in the kernel, glibc, suid programs,
>> etc.) and there are probably many we still don't know about. They
>> often require writing to the filesystem. For example, one fixed around
>> 5.4 just required the ability to make a symlink somewhere. The
>> published exploit script (which I've seen in the wild) tries to use
>> /tmp. If the httpd process can't write in /tmp, it would fail.
>>
>
> So are you saying that SELinux is supposed to prevent httpd from writing
> to /tmp ?
>
> Because I just tested that and SELinux didn't appear to stop it. I set
> selinux to "enforcing", rebooted just to make sure, and put this perl
> script on my webserver:
>
> #!/usr/bin/perl
> use IO::File;
> use strict;
> my $fh = IO::File->new("> /tmp/foo.txt");
> close($fh);
> print "Content-type: text/html\n\nDone.\n";
>
> then invoked it from the web, and this file was created:
> [root@g6950-21025 ~]# ls -l /tmp/foo.txt
> -rw-r--r-- 1 apache apache 0 Jan 2 16:47 /tmp/foo.txt
>
> [root@g6950-21025 ~]# cat /etc/selinux/config
> # This file controls the state of SELinux on the system.
> # SELINUX= can take one of these three values:
> # enforcing - SELinux security policy is enforced.
> # permissive - SELinux prints warnings instead of enforcing.
> # disabled - SELinux is fully disabled.
> SELINUX=enforcing
> # SELINUXTYPE= type of policy in use. Possible values are:
> # targeted - Only targeted network daemons are protected.
> # strict - Full SELinux protection.
> SELINUXTYPE=targeted
>
>
Actually, SELinux needs to let http write to tmp, otherwise scripts such as
those written in PHP will fail.
What it WON'T do is to let scripts execute from that directory. You have to
explicitly enabled it with:
setsebool -P httpd_tmp_exec on
So yes, it would have prevented attackers from launching exploit scripts in
/tmp. Of course, mounting /tmp as not executable would work the same, but that
requires that /tmp be a separate files system, which may not an option if the
server is already partitioned.*
- Rilindo
*It could work if you use --bind option. But I can't confirm that,
unfortunately.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Jan 2, 2012, at 9:30 PM, Bennett Haselton wrote: > On 1/2/2012 9:18 AM, Les Mikesell wrote: >> On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haselton >> wrote: >>> I tried SELinux but it broke so much needed functionality on the server >>> that it was not an option. >> Pretty much all of the stock programs work with SELinux, so this by >> itself implies that you are running 3rd party or local apps that have >> write access in non-standard places. Which is a good start at what >> you need to break in. What apps are those (i.e. the ones that >> SELinux would have broken) and if they are open source, have those >> projects updated the app or the underlying language(s)/libraries since >> you have? > > So here's a perfect example. I installed squid on one machine and > changed it to listen to a non-standard port instead of 3128. It turns > out that SELinux blocks this. (Which I still don't see the reasoning > behind. Why would it be any less secure to run a service on a > non-standard port? A lot of sources say it's *more* secure to run > services on a non-standard port if you don't want people poking around! > In general I don't think it's any more secure to run a service on a > non-standard port -- all it buys you is time, as it's trivial for an > attacker to scan all your ports, especially with a botnet -- but even if > it's not more secure, it certainly shouldn't be *less* secure.) > > But here's the real problem. Since I didn't know it was caused by > SELinux, all the cache.log file said was: > > 2012/01/02 17:40:40| commBind: Cannot bind socket FD 13 to *:[portnum > redacted]: (13) Permission denied > > Nothing indicating why. Even worse, if you Google > +squid +"cannot bind socket" +"permission denied" > *none* of the first ten pages that come up, mention SELinux as a > possible source of the problem. (One FAQ mentions SELinux but only as > the source of a different problem.) All they do is recommend other > workarounds, each of which takes time to test out, and may have other > side-effects. > > In other words, when SELinux causes a problem, it can take hours or days > to find out that SELinux is the cause -- and even then you're not done, > because you have to figure out a workaround if you want to fix the > problem while keeping SELinux turned on. > How is it SELinux's problem? Its like running iptables with the default http ports open and then blaming iptables when you change Apache to a non-standard port. SELinux's list of open ports is pretty extensive. You can use the semanage (part of policycoreutils-python package) to get the list of allowed ports and grep for specific items that are open by default (like http and squid): [root@kerberos kvm]# semanage port -l | grep http http_cache_port_t tcp 3128, 8080, 8118, 8123, 10001-10010 http_cache_port_t udp 3130 http_port_ttcp 80, 443, 488, 8008, 8009, 8443 pegasus_http_port_ttcp 5988 pegasus_https_port_t tcp 5989 - Rilindo ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/05/2012 04:36 PM, Bennett Haselton wrote: >> http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed >> between similar types, so Apache running as httpd_t can read >> /var/www/html/index.html of type httpd_sys_content_t." >> >> however the doc doesn't define what "similar types" means. I >> assumed it just meant "beginning with the same prefix". However >> that can't be right because on my system with SELinux turned on, >> httpd runs as type init_t: >> >> [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 >> system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 >> 8820 ?Ss 05:05 0:00 /usr/sbin/httpd >> system_u:system_r:init_t:s0 apache2550 0.0 0.4 23364 >> 8920 ?S05:05 0:00 /usr/sbin/httpd >> system_u:system_r:init_t:s0 apache2551 0.1 0.4 22736 >> 8212 ?S05:05 0:00 /usr/sbin/httpd >> >> and the robots.txt file has type file_t: [root@peacefire04 - /root >> # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root >> system_u:object_r:file_t:s0 /var/www/html/robots.txt >> >> but Apache can of course access that file. So in Type Enforcement, >> what determines what process type can access what file type? >> >> Bennett ___ CentOS >> mailing list CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > > > Your machine needs to be relabeled. > > touch /.autorelabel > reboot > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 > lFkAnjLTi3zphekGomv04ZyMu0sOuopg > =cIvM > -END PGP SIGNATURE- > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos WARNING: If you have never enabled SELinux for long time, the boot is going to take a while as the system relabels the whole machine. Do not do this unless you can plan for an extend downtime. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote: > Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit: > >> On 1/6/2012 4:11 AM, Philippe Naudin wrote: >>> Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit: >>> On 1/6/2012 2:24 AM, Philippe Naudin wrote: > Apache running as "init_t" is a call for troubles. Is it? OK, any idea what caused that and how to fix it? >>> No, sorry. Your httpd comes from CentOS ? >> Yes >>> Afaik, you should not have any process running in context init_t except >>> init itself. If "ps awuxZ | grep [i]nit_t" returns more than only init >>> and httpd, your problem is likely to be more complicated than a broken >>> configuration of apache. >> >> I've got a few... >> >> [root@g6950-21025 ~]# ps auwxZ | grep init_t >> system_u:system_r:init_troot 1 0.6 0.0 10368 712 >> ?Ss 04:17 0:00 init [3] >> >> system_u:system_r:init_troot 537 0.2 0.1 13728 1976 >> ?S> system_u:system_r:init_troot 1684 0.0 0.0 38880 456 >> ?Ssl 04:18 0:00 brcm_iscsiuio >> system_u:system_r:init_troot 1690 0.0 0.0 12152 476 >> ?Ss 04:18 0:00 iscsid >> system_u:system_r:init_troot 1691 0.0 0.4 12648 4460 >> ?S> system_u:system_r:init_tdbus 2081 0.0 0.1 31520 1144 >> ?Ssl 04:18 0:00 dbus-daemon --system >> system_u:system_r:init_troot 2215 0.0 0.1 52372 1492 >> ?Ssl 04:18 0:00 automount >> system_u:system_r:init_troot 2254 0.0 0.1 62656 1212 >> ?Ss 04:18 0:00 /usr/sbin/sshd >> system_u:system_r:init_tntp 2273 0.0 0.4 23412 5044 >> ?SLs 04:18 0:00 ntpd -u ntp:ntp -p /var >> /run/ntpd.pid -g >> system_u:system_r:init_troot 2287 0.1 1.0 253312 10580 >> ?Ss 04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2315 0.3 1.3 259488 13376 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2316 0.0 1.0 257436 11124 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2317 0.1 1.1 257436 11288 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2318 0.1 1.1 257436 11292 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2319 0.0 1.0 256720 10504 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2320 0.1 1.0 257436 10752 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2321 0.0 1.1 257436 11272 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache2322 0.1 1.1 257436 11356 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_troot 2386 0.0 0.0 3812 492 >> tty1 Ss+ 04:18 0:00 /sbin/mingetty tty1 >> system_u:system_r:init_troot 2387 0.0 0.0 3812 488 >> tty2 Ss+ 04:18 0:00 /sbin/mingetty tty2 >> system_u:system_r:init_troot 2390 0.0 0.0 3812 488 >> tty3 Ss+ 04:18 0:00 /sbin/mingetty tty3 >> system_u:system_r:init_troot 2392 0.0 0.0 3812 492 >> tty4 Ss+ 04:18 0:00 /sbin/mingetty tty4 >> system_u:system_r:init_troot 2394 0.0 0.0 3812 488 >> tty5 Ss+ 04:18 0:00 /sbin/mingetty tty5 >> system_u:system_r:init_troot 2397 0.0 0.0 3812 488 >> tty6 Ss+ 04:18 0:00 /sbin/mingetty tty6 >> system_u:system_r:init_tapache2405 0.1 1.0 256412 11008 >> ?S04:18 0:00 /usr/sbin/httpd >> system_u:system_r:init_troot 2406 0.3 0.3 90156 3456 >> ?Ss 04:18 0:00 sshd: root@pts/0 >> root:system_r:initrc_t:SystemLow-SystemHigh root 2458 0.0 0.0 61176 768 >> pts/0 S+ 04:18 0:00 grep init_t >> >> >> >> I also found at least one file (the audit.log file) which has file type >> file_t, even though I thought the filesystem had been re-labeled >> successfully because /var/www/html/robots.txt had the correct type: >> >> [root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt >> -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t >> /var/www/html/robots.txt >> [root@g6950-21025 ~]# ls -lZ /var/log/audit/audit.log >> -rw--- root root system_u:object_r:file_t >> /var/log/audit/audit.log >> >> >> Any idea (1) what could be causing that and (2) whether it could be >> related to the problem with all those init_t processes? > > It's easy : your init process is broken, all these daemons but init > are mis-labeled, so all the files they create (such as log files) are > mis-labeled. > > And if the next question is "how to fix it ?", the answer is easy > too : "I don't have any clue..." > > Assuming that httpd came from CentOS, it should be appropriate relabeled
Re: [CentOS] SELinux and access across 'similar types'
On Jan 5, 2012, at 7:37 PM, Bennett Haselton wrote: > On 1/5/2012 3:14 PM, RILINDO FOSTER wrote: >> On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 01/05/2012 04:36 PM, Bennett Haselton wrote: >>>> http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed >>>> between similar types, so Apache running as httpd_t can read >>>> /var/www/html/index.html of type httpd_sys_content_t." >>>> >>>> however the doc doesn't define what "similar types" means. I >>>> assumed it just meant "beginning with the same prefix". However >>>> that can't be right because on my system with SELinux turned on, >>>> httpd runs as type init_t: >>>> >>>> [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 >>>> system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 >>>> 8820 ?Ss 05:05 0:00 /usr/sbin/httpd >>>> system_u:system_r:init_t:s0 apache2550 0.0 0.4 23364 >>>> 8920 ?S05:05 0:00 /usr/sbin/httpd >>>> system_u:system_r:init_t:s0 apache2551 0.1 0.4 22736 >>>> 8212 ?S05:05 0:00 /usr/sbin/httpd >>>> >>>> and the robots.txt file has type file_t: [root@peacefire04 - /root >>>> # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root >>>> system_u:object_r:file_t:s0 /var/www/html/robots.txt >>>> >>>> but Apache can of course access that file. So in Type Enforcement, >>>> what determines what process type can access what file type? >>>> >>>> Bennett ___ CentOS >>>> mailing list CentOS@centos.org >>>> http://lists.centos.org/mailman/listinfo/centos >>> >>> Your machine needs to be relabeled. >>> >>> touch /.autorelabel >>> reboot >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 >>> lFkAnjLTi3zphekGomv04ZyMu0sOuopg >>> =cIvM >>> -END PGP SIGNATURE- >>> ___ >>> CentOS mailing list >>> CentOS@centos.org >>> http://lists.centos.org/mailman/listinfo/centos >> WARNING: If you have never enabled SELinux for long time, the boot is going >> to take a while as the system relabels the whole machine. Do not do this >> unless you can plan for an extend downtime. >> >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > I did do > touch /.autorelabel > reboot > > The machine booted back up in just a few minutes, what looked like > normal reboot time. And then I ran the same commands as before and got > what looks to me like the same output: > > [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt > -rw-rw-rw- root root system_u:object_r:file_t:s0 > /var/www/html/robots.txt > [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 > system_u:system_r:init_t:s0 root 2530 0.0 0.4 21680 8820 > ?Ss 16:23 0:00 /usr/sbin/httpd > system_u:system_r:init_t:s0 apache2558 0.8 0.8 28308 16392 > ?S16:23 0:03 /usr/sbin/httpd > system_u:system_r:init_t:s0 apache2560 0.5 0.5 23248 10236 > ?S16:23 0:02 /usr/sbin/httpd > > So I'm wondering: > 1) How did you know that the machine needed to be relabeled, was it > something in the output of the commands the first time I ran them? and > in that case, > 2) Why didn't it change after I created /.autorelabel and rebooted? > (I can confirm the file /.autorelabel is no longer present, so it must > have been deleted when the auto-relabel was done, like the doc says.) > 3) If the machine booted back up very quickly, should I be worried that > the autorelabel might not have happened? Any idea if it logs a message > somewhere if it fails to start properly? > ___ > That sort of sound like a good thing. I would suggest that you do: tail -f /var/log/audit/audit.log | audit2allow To see what type of alerts you are getting. Likely you will get a lot, as some of the file contexts may not be labeled correctly. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Jan 6, 2012, at 10:35 AM, Bennett Haselton wrote: > > I tried that and it worked -- the httpd processes are now listed with > "httpd_t" as their context, the /var/log/audit/audit.log file is listed > with auditd_log_t as its type instead if file_t, etc. > > I'm pretty sure this machine was never "upgraded to CentOS 5.2", it was > just imaged with 5.7 when the hosting company set it up, but SELinux > *was* off until I turned it on. So probably the doc should say, if the > "system was *installed* with 5.2, then do this" (and presumably it's 5.2 > or later, not just 5.2). Either that, or the base install was an earlier version of Centos 5.x, with SELinux turned off then upgraded to the current version. - Rilindo ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On Jan 10, 2012, at 7:51 PM, Timothy Murphy wrote: > I've been getting a few avahi-daemon errors in /var/log/messages, eg > --- > Jan 11 00:40:24 helen avahi-daemon[12732]: Invalid query packet. > > Jan 11 00:40:29 helen last message repeated 17 times > > --- > > (This is on a CentOS-5.7 server.) > > So I looked up avahi on the web, but as far as I could see > it is not doing anything essential; > so I was wondering if stopping avahi-daemon would have any bad effect? > > > -- > Timothy Murphy > e-mail: gayleard /at/ eircom.net > tel: +353-86-2336090, +353-1-2842366 > s-mail: School of Mathematics, Trinity College Dublin > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos Avahi is a mdns daemon. You can safely disable it in most cases. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
