Fresh Load Kernel 2.6.40.6-0.fc15.i686.PAE mdadm-3.2.2-14.fc15.i686 systemd-26-13.fc15.i686 issue a sudo shutdown -r 0 get Dropping to debug shell. sh: can't access tty; job control turned off dracut:/# Target Dell Optiplex 990 Intel Matrix RAID Do y'all test against real hardware because in less that 10 mins after a load it happens.... here is how I test load with a kickstart file yum update yum update from test login in as root try reboot shutdown -r 0 shutdown -h 0 add user add user to sudoers user1 ALL=NOPASSWD: /sbin/shutdown as root reboot login as user issue a sudo shutdown -r 0 most of the time the first try fails. if the system does not comeback up power off then back on and you will have this failure..... Please let me know I will test I have 9 i7 machines on my burn in rack to test with. thanks
Yes we do indeed test on real hardware, however adding a user to sudo in order for the user to be able to call shutdown -r 0 isn't the most common nor recommended usage case. Does this problem still occur under Fedora 16? On a side note, you really would want x86_64 on there to avoid the system using bounce buffers constantly when running the i686 kernel. Jes
Hello I ask about hardware because we can not reproduce the issue using VBox or VMware, only on the targets. what would your commendation be for a non-administrative user to reboot / shutdown a system that does not operate a windows manager? Sudoers file has a commented line that allows all users to issue a reboot / shutdown this is not acceptable for as as it is not in compliance with our security plan toallow everybody to shutdown/reboot. But if you uncomment that line and allow users same issue. from /etc/sudoers # %users localhost=/sbin/shutdown -h now Testing in F16 has Not reproduce the issue, but there is an issue with the box stopping the process and a hard power off required. not sure if that helps or hurts. Bug https://bugzilla.redhat.com/show_bug.cgi?id=752593 Can not move the x86_64 third party components will not move and have not replaced them all as of yet. Stuck with i386 tree only.... We are pushing to try to get there. Note sure what to do today we have been shipping i7 machines which required me to move away from FC11 (were going to update all filed systems to FC15 but have stopped) and did not see this issue until we YUM a production box to fix a different issue and started seeing this RAID problem..... we are doing some funny things right now in our build process to get the set of packages we need to run but if a field machine is YUMed they will pretty much lose some data. Not good I understand. So your recommendations would to move to x86_64 and not let users reboot only root or process running with hight enough privileges.
If you really wish for all users to be able to reboot the system you could simply suid the /sbin/shutdown binary - still I would not recommend this, just as I wouldn't recommend what you are doing. How is your system configured? Are the user's home directories located on the RAID device? is / on the RAID? Jes
Yes "/" down is on the raid. So what is the method for rebooting a box as a non root user? Yes adding s bit to the shutdown it what most people state, but that allows all ... just trying to follow good layered security for hipaa. Which requires a user to admin certain parts of the box without access to others. I am calling all my vendors today and see about fc16 with x86_64 Thanks
well if it works for root to do the shutdown, it might work for you to let the user execute 'su -c /sbin/reboot' through sudo. My guess is that something goes wrong because it is unable to unmount the raid because something through the chain of the sudo call keeps some user file descriptor open on the raid. The problem with IMSM RAID is that the metadata is managed through mdmon, so as long as the RAID is read-write, you cannot shutdown mdmon, and allow for a clean reboot.
Hello thanks we will be moving to Fedora 16 and dealing with upstream issues the RAID support seams better can not reproduce the issue in Fedora 16 thanks again.