Solved How can I change the root shell to csh

N

Niklo

Hello,
is there a possibility to make/set csh as root shell again?

I started with Linux in 1997. In the early 2000 I used FreeBSD and NetBSD for a while and was surprised and impressed to see that SunOS 4 was a BSD Unix, too with a lot of similarities. I learned to love the csh. :-) What I loved in BSD was the little memory consumption compared to the fast "growing" Linux systems. After changing the job we used Linux so I used Linux again at home, too.
Now in the current Christmas holidays I tried FreeBSD 14.2 on my Raspberry 3b and was surprised and a bit disappointed that the csh is no longer the root shell. I tried out to change the shell in /etc/passwd but that doesn't help to change the root shell. Now both root and toor have the sh or bash.
Why has the root shell changed? Is there an eays possibility to make the csh as root shell again.
It is long time ago so maybe don't remember exactly. In former times there was a static build sh and csh in /sbin. Was it just in Solaris or SunOS or in FreeBSD and NetBSD, too?
Is there a static build sh and csh for FreeBSD?
Although I used FreeBSD and NetBSD 20 years ago for a while I forgot a lot of detail and feel like a FreeBSD newbie again. :) I am happy for any advice.
Kind regards,
Roland
 
Niklo said:
is there a possibility to make/set csh as root shell again?
Click to expand...
Of course.

Niklo said:
I tried out to change the shell in /etc/passwd but that doesn't help to change the root shell.
Click to expand...
Never edit /etc/passwd. This file isn't even used anymore, it's just there for some really ancient backwards compatibility. Just use chsh(1) to change the shell.
 
SirDice said:
Of course.


Never edit /etc/passwd. This file isn't even used anymore, it's just there for some really ancient backwards compatibility. Just use chsh(1) to change the shell.
Click to expand...
Thank you very much. I've changed /etc/passwd back and used chsh(1) and it worked perfekt. Super :)

I guess that there is no statically linked shell like e.g. /sbin/csh in the modern FreeBSD, correct? I probably I remembered it from an ancient Unix...

Kind regards,
Roland
 
Thank you Adorno. Wow, all important commands are available there statically linked and it's the same binary that contains all commands ! Now I learned something new again. It's different from what I remembered but it seems even better. :)
Kind regards,
Roland
 
SirDice said:
Of course.


Never edit /etc/passwd. This file isn't even used anymore, it's just there for some really ancient backwards compatibility. Just use chsh(1) to change the shell.
Click to expand...
It depends.
You can edit indirectly using "vipw" which locks files, checks and updates after editing. So whole operation is kosher. ;)
 
Varek said:
It depends.
You can edit indirectly using "vipw" which locks files, checks and updates after editing. So whole operation is kosher. ;)
Click to expand...
Hello Varek,
thank you very much. I will try to remember both vipw and chsh. Probably chsh is preferred and less "error prone" to work with. I used chsh and it worked while vi /etc/passwd didn't work. There are a lot of other things I have to learn (again).
Kind regards,
Roland
 
Varek said:
You can edit indirectly using "vipw" which locks files, checks and updates after editing. So whole operation is kosher.
Click to expand...
Doesn't edit /etc/passwd, although it may appear that way. That file is generated from /etc/master.passwd, which is what you're really editing with vipw(8) (or any of the other commands). The 'old' /etc/passwd file is actually never used anymore. See pwd_mkdb(8).
 
SirDice said:
Doesn't edit /etc/passwd, although it may appear that way. That file is generated from /etc/master.passwd, which is what you're really editing with vipw(8) (or any of the other commands). The 'old' /etc/passwd file is actually never used anymore. See pwd_mkdb(8).
Click to expand...
Yes, that's what i ment.
AFAIK /etc/master.passwd was used and /etc/passwd regenerated only for System 7 compatibility (am i wrong?) in FreeBSD from the beginning.
At least for me it was "always" this way (practically starting from FreeBSD 2.2).
I prefer to use vipw because i am lazy and have no memory. xd
For scripting i use "pw" anyway as swiss army knife for users, groups, etc.
 
adorno said:
Have a look inside /rescue and guess again...
Click to expand...
Some appendixes:

And you'll find all binary executable files in /rescue has exactly the same sizes and timestamps (except text files like scripts).

This is because these binaries are hard-linked to so called crunch binary that containes all of the statically linked (to required libraries) and changes its behavior by the name (argv[0]) it is invoked.
See crunchgen(1) man page for details.
 
Varek said:
You can edit indirectly using "vipw" which locks files, checks and updates after editing. So whole operation is kosher.
Click to expand...
If anyone NOT YET learned vi(1) want to use vipw(8), the person doesn't need to learn vi(1) with the reason alone.

vipw(8) honors environment variable EDITOR. By setting it ee(1), vipw(8) invokes /usr/bin/ee instead of /usr/bin/vi (the default).

Note that vi(1) is a quite powerful editor and worth learning even now, 21th century. But if not yet familiar and forced to do something with vipw(8) and etcupdate(8), setting EDITOR environment variable to something the person is already familiar and can be run at the situation (ee(1) would help newbies much here).
 
SirDice said:
The 'old' /etc/passwd file is actually never used anymore.
Click to expand...
To be more precise, FreeBSD base doesn't refers to it, and most of ports/pkgs would be, too.
But old programs in the wild (and possibly some of programs in ports/pkgs) could want /etc/passwd to be kept in sync with /etc/master.passwd, as the programs doesn't know about user database files other than /etc/passwd.
This would be the reason /etc/passwd is still generated.
 
T-Aoki said:
But old programs in the wild (and possibly some of programs in ports/pkgs) could want /etc/passwd to be kept in sync with /etc/master.passwd, as the programs doesn't know about user database files other than /etc/passwd.
Click to expand...
That is the argument that's been given, yes. But, I'm fairly certain nothing ever does, or did, even in the olden days. Applications typically use getutxent(3) and associated functions. And before that it was getpwent(3). Can you name an application that uses /etc/passwd directly? Honestly, the only things I've seen that would try to access /etc/passwd directly are PoC exploits.
 
tedbell said:
Will changing back to csh cause any problems?
Click to expand...
That's what OP want to do, isn't it?

And I cannot recommend any shell which doesn't live in /bin/ to be registered as login shell.
Instead, although I'm using zsh as my command line shell, my login shell registered is /bin/tcsh (same as /bin/csh, hard linked by default on install).
But I don't need manually invoking zsh everytime, as I have the configuration below in my ~/.tcshrc.mine.

Code: 
if ( -X zsh && -f ~/.Use_zsh ) exec zsh

This is in csh syntax (as it is the configuration for it), and invoke zsh, altering tcsh, only if zsh exists somewhere in the PATH and executable, and ~/.Use_zsh (blank file as a marker) exists.

This way, when zsh cannot be found (i.e., zsh is deinstalled, /usr/local is not mounted,...), (t)csh keeps on running. And I can manually direct not to invoke zsh automatically by renaming or removing the marker file, without touching anything else.
 
Thank you for all your answers.
Changing back to csh with chsh worked well and I don't have had any problems so far. I works perfect. :) So the topic is solved for me.
I found some other probably Raspberry PI related problems but I will open another thread.

Kind regards,
Roland
 
SirDice said:
...I'm fairly certain nothing ever does, or did, even in the olden days.
Click to expand...
Things definitely did back in the olden days.
Jose

Solved Post in thread 'What purpose does /etc/passwd serve in FreeBSD?'

Traditionally, each line in /etc/passwd consists of seven fields; the second field contains a string that represents the user's encrypted password. Since /etc/passwd must be world-readable for commands like ls to work, the encrypted password string is available to all users on the system. Evildoers can encrypt selected dictionaries or words and compare the results with the strings in /etc/passwd. If the encrypted strings match, a password has been found.
Click to expand...
Nemeth, Snyder, Seebass, and Hein: UNIX System Administration Handbook, second edition, page 543.
 
SirDice said:
Doesn't edit /etc/passwd, although it may appear that way. That file is generated from /etc/master.passwd, which is what you're really editing with vipw(8) (or any of the other commands). The 'old' /etc/passwd file is actually never used anymore. See pwd_mkdb(8).
Click to expand...
Yes. Never edit /etc/passwd, /etc/shadow, /etc/master.passwd, Trusted Computing Base any other password file any UNIX or Linux system. Use chsh, adduser, rmuser, pw, chpass, pw, useradd, usermod, and userdel (last three are Linux specific). Unless you ABSOLUTELY know what you're doing, *always* use the tools provided by the O/S. I've seen too many people dig themselves into a hole by editing the passwd files.

At $JOB we use a collection of ansible playbooks and roles to manipulate authentication and access.

At $JOB I am advocating all admins lose shell access. All admin must be done using the tools provided, in our case ansible. Except for a select few senior admins to fix problems others have caused or nobody else can resolve, nobody should have shell access to any server.
 
cy@ said:
At $JOB I am advocating all admins lose shell access. All admin must be done using the tools provided, in our case ansible. Except for a select few senior admins to fix problems others have caused or nobody else can resolve, nobody should have shell access to any server.
Click to expand...
I'm not sure whether I think that reflects on the competence of the admins or the competence of the management.

But I do think that there are many things that ansible can not do, and a person without root shell access is not a professional system administrator..

I'm not suggesting that there is not room for "para-technical" support people, but they are not system administrators.

The factory of the future will have only two employees, a man and a dog.
The man will be there to feed the dog.
The dog will be there to keep the man from touching the equipment.
-- Warren Bennis, U.S. leadership guru​
 
gpw928 said:
I'm not sure whether I think that reflects on the competence of the admins or the competence of the management.

But I do think that there are many things that ansible can not do, and a person without root shell access is not a professional system administrator..

I'm not suggesting that there is not room for "para-technical" support people, but they are not system administrators.

The factory of the future will have only two employees, a man and a dog.​
The man will be there to feed the dog.​
The dog will be there to keep the man from touching the equipment.​
-- Warren Bennis, U.S. leadership guru​
Click to expand...
Maybe there's several "Wizard" sysadmins that already can/allowed full access to the servers, physically and (optionally via network).
Without them (at least 5 per datacenter and any of 2 can go to the datacenter physically as at minimum 2 man cell 24Hrs/366Days for enterprize class), hazards that never be experienced cannot be resolved.
(I assume cy@ would be one of them. ;) )

Depending on the whole bunch of those onto outsourced parties should be the largest risk. At worst, any internal admin who can look into what outsourced parties is doing, understanding it and stop them when needed should be with them just in time, just in place. Of course, "Wizard" class admins would be better being officers (not limited with CTO) to decide quite important things just in time.
 
You must log in or register to reply here.
Back
Top