In NodeWorx under SiteWorx “Shell Users” one can change all the user’s shells, EXCEPT root!
I need to be able to change the root user’s shell.
And for that matter an option to disallow login by root too!
RWF, you really don’t want to disable root’s shell. That ability is disabled in NodeWorx because it is a bad idea. If this setting was enabled in NodeWorx I guarantee there would be an endless stream of users locking themselves out of their server and blaming us.
Disallowing root logins VIA SSH is probably what you wanted to do - but changing root’s shell is not the same thing.
You COULD disable root’s shell IF you had a secondary “root” user (with user id and group id 0) and only used this secondary user as “root”. But it’s still unncessary - if you had this secondary user set up, you should just set the root user’s password to a long random string of characters and leave the shell alone.
Paul
Paul this feature request was actually more about allowing us administrators to change the root user “folder” or shell, just like one can change it for all the other users under NodeWorx | SiteWorx | Shell Users"
I need to be able to change the root user’s shell.
In NodeWorx under SiteWorx “Shell Users” one can change all the user’s shells, EXCEPT root!
I need to be able to change the root user’s shell.
Sorry RWF, I was responding to the initial message content, quoted above, which seems to be talking about shells, not folders. The message and title seemed to conflict so I was confused.
Anyway, we’ll take this under advisement. This is the first I’ve heard of someone wanting to change root’s home directory.
Paul
Besides I read all over the Internet that the allowing root login is a security risk and that it is not needed.
I have used “usermod” to change the root “folder” or shell to /bin/nologin, and now I can’t “su -” to root when logging in as another user, something non-InterWorx users is able to do. It now gives me an an error:
su: /bin/nologin: No such file or directory
Which is why I posted my feature request of allowing me the change the root shell like I can with all the other user’s I could fix this problem real easy.
I have now been told by IWorx-SocHeat that Sago needs to do an emergency boot, read US dollars, mount another partition, and fix /etc/passwd manually.
Sorry first of all I have 40 accounts/sites running full steam, secondly if this machine is not gonna work like other Linux setups, speaking about the above problem of usermod and not being able to su to root, plus I can’t add an Apache module, I rather cut my ties now, buy another machine, without Interworx which is a shame because I do like your interface, learn the dreaded “Webmin” and port the sites over to that, then discontinue the first box.
Your confused? Well I am even more confused 
This /bin/nologin sounds like a folder to me but maybe it’s a shell, in a nutshell!
The request only came about because I was not able to “su -” to root, and now my root is screwed, after having used usermod -s /bin/nologin root, something that seems to be possible by non-Interworx users.
This is working like other Linux setups. Linux is doing exactly what you asked: disable the root user from logging in. I think you have a few things confused.
Setting the root user’s “folder” is not the same thing as setting the root user’s “shell”. The root user’s folder is “/root”. The root user’s “shell” (the command line interpreter) is typically set to “/bin/bash”, which is an executable file not a directory. They are two entirely separate things, and changing one does not change the other.
Any user who wants shell access must have a valid “shell” set, and setting the shell to /sbin/nologin disables shell access for that user. This means disabled login access from the console, from ssh, even from using ‘su’ as a another user. Additionally, the correct command for disabling shell access is:
usermod -s /sbin/nologin <user>
not /bin/nologin. Neither command should be run on the root user.
Shell access is not the same as SSH access. SSH access is the ability to login to a box remotely over a secured connection. Shell access just means the user can login to the box. Allowing root SSH login can be a security risk, but not root login in general. You obviously need to be able to login as root under certain circumstances. Once you get your root access back, please see my previous post on how to edit the SSH config file to disable root SSH logins.
If there’s something we could do to help, we would - but anything we would do would require us logging in as root - which unfortunately isn’t possible with the shell set to “/bin/nologin”. We can’t even get in to change InterWorx code. I’m afraid your stuck between a rock and a hard place. 
Are you telling me that any future Interworx updates will now not work/be installed on my computer?
I’m honestly not sure if the updates would apply with root’s shell set to an invalid value or not, I’ve never tried. Regardless, we can’t make an entire release to temporarily enable functionality in NodeWorx that may or may not work, just for this issue - building a takes a lot of time.
Having sago fix this shouldn’t be a very big deal. The best thing to do is to schedule a maintenance window for them to fix the /etc/passwd file. I can’t see it taking more than 15 minutes of downtime.
Paul
Well of course I understand you guys can’t release something for just me, and anyways nothing in a rush.
One final question before I need to make a big decision.
Is adding an Apache module on a Linux box with Interworx different than say if the box were using CPanel, Webmin, Plesk, etc.?
I did the same thing and locked root from having shell access. Sago was able to fix it and what I was trying to do and now do is blocking SSH access for root. Which means logining in as another user and SU’n. I do it more complicated thant that just b/c I’m paranoid, but basically the same end result.
I am a little confused as to now in three different threads, no one from InterWorx has replied about Apache modules.
Obvisouly I am not a Linux expert, and my question may not be relevant, but I really find it frustrating that I now have to ask it the fourth time!
Is adding an Apache module on a Linux box with Interworx different than say if the box were using CPanel, Webmin, Plesk, etc.?
Are you still referring to your mod_bwshare module? If so, this is what I did to get it installed (as root)
yum install apr-devel
yum install apr-util-devel
Then, I was able to run the installation instructions, without any problems, from the site you provided:
http://www.topology.org/src/bwshare/README.html
under “Installation of bwshare as a DSO module for Apache 2”
I did not attempt to configure mod_bwshare. It worked for me, on a CentOS 4.2 box, so it definitely is possible, but your results may vary. However, I must say that this is not officially supported by InterWorx as this is configuring the system Apache, which is provided by the distribution and not by us.
Thank your VERY much IWorx-SocHeat for your much appreciated help regarding that module.
My a bit more specific question here however was, if installaing an Apache module on a Linux box using InterWorx is different from Linux boxes using other management systems.
Hope to get that one answered too, but thanks again for going out of you way regarding the mod_bwshare module!
BTW I think things went wrong because I mistakenly did “usermod -s /bin/nologin” instead of “usermod -s /sbin/nologin”. Had I done that I could perhaps have used “su -” to switch to root.
One typo is all it took to mess it up
Another reason for adding features, in the future, for root user management, including disallowing direct logins, so Linux rookies like me won’t mess up their boxes 
It’s not any different than other Linux boxes. The general steps are the same. You’re working with the system apache, which is installed by the distribution. Each distribution may have it’s own preferred way of doing it, but installing InterWorx doesn’t change the procedure. You will still need to somehow create the .so module which, depending on the module, may require compiling manually, running apxs, or other commands. Some modules are available in packages (Debian has a deb package for a variety of apache modules), but again, it will depend on your distribution.
I don’t think that would’ve solved the problem, because setting the shell to /sbin/nologin disables shell access entirely. No attempt to get into the system as that user will work. You would most likely get this message:
This account is currently not available.
Again, just so there’s no confusion, what you’re looking for here is disabling SSH root logins. Disallowing direct root logins is what you ended up discovering, and is obviously not ideal. You’ll be happy to know that disabling SSH root logins is in the next release of InterWorx.
Im sure you know this arleady, but…
Im not sure how the other panels work, but Iworx was designed to allow you to modify apache without affecting Iworx itself. There is a totally different apache and mysql running for Iworx.
Actually it is the other way around, I think :), I wanted to disallow DIRECT root login. Meaning that potential hackers could not use that username and “only” had to guess the password. I could then login using my totally unknown username and “su -” to root. That is what I wanted to do!
You couldn’t quite do exactly that. If you disable direct root login, no one would be able to switch to the root user, even if you knew the password. This has nothing to do with InterWorx, but is part of Linux.
What you’d want to do is either set up ‘sudo’ correctly for your ‘unknown’ user, so that you can still run root commands, just not as the root user. Then, set the root password to some gibberish, and only use ‘sudo’
Or, you could do what Paul suggested earlier in this thread and create a secondary root user, and again set the main root password to gibberish.