I changed /etc/passwd for root to use bash

Let me guess: you just edited /etc/passwd directly instead of using vipw(8), right?

Not to mention that what you tried to do is a bad idea anyway. Just leave root's shell as it is.
 
Actually this is simply FreeBSD's hidden safety mechanism to avoid disasters ;)

To be quite honest I wouldn't even use vipw for this, my personal preference is chsh, simply because it has some extra failsaves to prevent you from messing things up. Something which is still a liable risk even when using vipw.

Either way, I also want to stress out that using bash is a bad idea. You really don't want to treat FreeBSD as if it were a Linux distribution, even though they have some similarities. The reason I'm mentioning this is because you create the impression that you simply want to make things easier for the root user. Yet normally there would be no need because the root account isn't something you normally want to use in your day to day operations.

Edit: If you do need easier access to the root account, perhaps because you need to perform lots of tasks which require root privileges, then you might want to take a look at security/sudo.
 
shells/bash is not included in the base system. It is a port and is installed in /usr/local/bin. If this is at a separate filesystem which fails to mount during boot, you have one more thing to worry about.
 
Code: 
chihiro:/home/peter $ grep root /etc/passwd
root:*:0:0:Chihiro administrator:/root:/bin/csh
But if you need something less 'arcane' (in all fairness, the C-Shell is a bit specific) then /bin/sh would be a proper substitute.
 
ShelLuser said:
Either way, I also want to stress out that using bash is a bad idea. You really don't want to treat FreeBSD as if it were a Linux distribution, even though they have some similarities. The reason I'm mentioning this is because you create the impression that you simply want to make things easier for the root user. Yet normally there would be no need because the root account isn't something you normally want to use in your day to day operations.
Click to expand...
It's not really a matter of having the wrong attitude toward root. It has everything to do with bash being a port and not being a part of the base system. This means that it can break, or a dependency can break, making the root account unusable.

Also, I generally use pw to make changes to user accounts, since it makes sure all of the right files are changed/recompiled.

Kevin Barry
 
ta0kira said:
It's not really a matter of having the wrong attitude toward root. It has everything to do with bash being a port and not being a part of the base system. This means that it can break, or a dependency can break, making the root account unusable.
Click to expand...
Well, that's a semantic I don't quite share because the very moment you fire up FreeBSD in single user mode, the first question it'll ask is what shell you wish to use. If I recall correctly it even defaults to /bin/sh.

And the reason I was wondering about "making the root environment easier" is because on Linux /bin/bash (Linux path) is the shell for the root user. And although /bin/sh is also perfectly usable I do think its fair to say that Bash provides more functionality.

And that trigged my assumption up there.

ta0kira said:
Also, I generally use pw to make changes to user accounts, since it makes sure all of the right files are changed/recompiled.
Click to expand...
That's quite a good one.. I once used it to add a user to a different group, and although I got a bit overwhelmed at first it is quite consistent where syntax is concerned.
 
gkontos said:
Never use a shell for the root user that is not included in the root (/) filesystem!
Click to expand...

Exactly. If you keep /usr or /usr/local in a separate partition, you will automatically not be able to boot into a single-user mode (well, this may not be true, because user-specific configuration isn't read at that time yet). But, you can still fix it pretty easily, using live media.

However, I know how frustrating csh family of shells can be at times (lack of functions for example makes your ~/.(t)cshrc a lot less flexible), but I have decided to just stick with tcsh for all my accounts.

But if you insist on using a different shell that comes with ports, consider installing shells/zsh + security/sudo for your normal user account. This would be safe (not in the security manner, but rather it wouldn't cause system breakage due to a different shell). You would have more power, far better auto completion than bash or any other shell, and still use it for administrative tasks without worrying if it will render your system "unbootable" (which actually happened to me in December).

Next time, while logged in as the specific user, you can change shells with $ chsh -s zsh (to change for example to zsh), as is also described in the handbook.
 
There's nothing wrong in using a non-standard shell for root, just use it in a safe way. You could put something like this at the top of /root/.cshrc:
Code: 
if ( -x "/usr/local/bin/mksh" ) then
        exec /usr/local/bin/mksh
end
 
jalla said:
There's nothing wrong in using a non-standard shell for root, just use it in a safe way. You could put something like this at the top of /root/.cshrc:
Click to expand...
Another way of safely specifying a non-standard shell for root is to use the toor account for that. I actually have it disabled because I don't need/want it, but that's what it's for.
 
storvi_net said:
Is there any problem by typing # bash after logging in? This is the way I administrate systems for all the years.
Click to expand...
Problem is a bit overstated, but it's probably easier to enable the toor account and use that for logging in.
 
I've used bash as the root shell for years, since FreeBSD 4.1 at least and never had a single problem. The advice to not do this is definitely given for a very good reason but as long as you know what you are doing I don't see the problem with doing this. I personally have / and /usr/local on the same filesystem. The port is configured with "Build static executables and/or libraries". And I am aware of how to use single user mode to select an alternative shell like /bin/sh or at the very worst /rescue/sh. If your setup is similar then there's no problems. If it's not then the alternative advice in this thread is the way to go.
 
xtaz said:
I personally have / and /usr/local on the same filesystem.
Click to expand...
That does help, of course. But you presumably deliberately chose to do that. Most people won't have / and /usr/local on the same filesystem.
 
chatwizrd said:
Why do you think that?
Click to expand...
I should probably rephrase that: most new users using the guided/automated partitioning probably won't bla bla bla.

Thanks for pointing out my error.

In most cases /usr/local will be either a separate partition or it will be part of /usr, but not of / because most people have at least / and /usr separated.
 
fonz said:
... In most cases /usr/local will be either a separate partition or it will be part of /usr, but not of / because most people have at least / and /usr separated.
Click to expand...

This is old teaching, i.e. pre-9.x disk layout.

The new teaching lets new users put everything into the same partition.
 
storvi_net said:
Is there any problem by typing # bash after logging in? This is the way I administrate systems for all the years.
Click to expand...
You'll lose some aspects of job control since bash won't be the session leader. exec bash is a better way to go so it takes over the terminal.

Kevin Barry
 
fonz said:
Whoa, when did that happen? Sounds like a bad idea to me.
Click to expand...

Interesting to see that it's actually in the handbook to do that now. I never realised that! But yes, the example in there is pretty much how I've always partitioned my servers since I first started using it around 4.1. I just create a single 4K aligned / partition and use it for everything.

The only reason I can see for it being a bad idea is if your services get DoS'd from the internet and log files or mail spool files build up in /var or /tmp. However I have never ever seen this actually happen so I think the risk is very low, and also I believe there is a "reserved" part of the filesystem which only the root user can use so it will never actually hit 100% used, or rather it will or it will allow root to use 105%. Something along those lines? So you can still happily use the server and fix it.

Also in the old days of 50 MB hard drives this was obviously very important. Now we have terabytes of storage it would take A LOT of log files or emails to fill a disk up. I guess that's probably why the handbook advice has changed. It could actually cause more problems not having large enough partitions to install ports or install a new bootloader etc rather than just one large one.
 
fonz said:
Whoa, when did that happen? Sounds like a bad idea to me.
Click to expand...

bsdinstall(8) does it by default. I'm unaware if there was any discussion of it beforehand, although I do know it was questioned afterward.

The Handbook documents what bsdinstall(8) does. It is not a recommendation, although the distinction is small. Later on, an example shows a split filesystem setup.
 
You must log in or register to reply here.
Back
Top