# I changed /etc/passwd for root to use bash



## idaho-axe (Jun 8, 2013)

*B*ut it seems to come up with csh. *W*hy?


----------



## fonz (Jun 8, 2013)

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.


----------



## ShelLuser (Jun 8, 2013)

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.


----------



## idaho-axe (Jun 8, 2013)

*H*m*,*

*O*k*.*

*R*everting bash to what was it /bin/sh?


----------



## marwis (Jun 8, 2013)

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.


----------



## ShelLuser (Jun 8, 2013)

```
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.


----------



## idaho-axe (Jun 8, 2013)

*O*k it*'*s back to /bin/cash /bin/csh for safety*.*


----------



## ta0kira (Jun 8, 2013)

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.


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


----------



## ShelLuser (Jun 8, 2013)

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.


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.


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 (Jun 9, 2013)

Never use a shell for the root user that is not included in the root (/) filesystem!


----------



## jozze (Jun 9, 2013)

gkontos said:
			
		

> Never use a shell for the root user that is not included in the root (/) filesystem!



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.


----------



## idaho-axe (Jun 9, 2013)

I already said I changed it back to /bin/csh*.*


----------



## jalla (Jun 9, 2013)

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:

```
if ( -x "/usr/local/bin/mksh" ) then
        exec /usr/local/bin/mksh
end
```


----------



## fonz (Jun 10, 2013)

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:


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 (Jun 16, 2013)

Is there any problem by typing `# bash` after logging in? This is the way I administrate systems for all the years.

Markus


----------



## fonz (Jun 16, 2013)

storvi_net said:
			
		

> Is there any problem by typing `# bash` after logging in? This is the way I administrate systems for all the years.


Problem is a bit overstated, but it's probably easier to enable the toor account and use that for logging in.


----------



## xtaz (Jun 18, 2013)

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.


----------



## fonz (Jun 18, 2013)

xtaz said:
			
		

> I personally have / and /usr/local on the same filesystem.


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 (Jun 18, 2013)

fonz said:
			
		

> 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.



Why do you think that?


----------



## fonz (Jun 18, 2013)

chatwizrd said:
			
		

> Why do you think that?


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.


----------



## Anonymous (Jun 18, 2013)

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.



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

The new teaching lets new users put everything into the same partition.


----------



## fonz (Jun 18, 2013)

rolfheinrich said:
			
		

> This is old teaching, i.e. pre-9.x disk layout.
> 
> The new teaching lets new users put everything into the same partition.


Whoa, when did that happen? Sounds like a bad idea to me.


----------



## ta0kira (Jun 18, 2013)

storvi_net said:
			
		

> Is there any problem by typing `# bash` after logging in? This is the way I administrate systems for all the years.


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


----------



## xtaz (Jun 20, 2013)

fonz said:
			
		

> Whoa, when did that happen? Sounds like a bad idea to me.



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.


----------



## wblock@ (Jun 20, 2013)

fonz said:
			
		

> Whoa, when did that happen? Sounds like a bad idea to me.



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.


----------

