Solved How can I change the root shell to csh

[cy@]

I'm not sure whether I think that reflects on the competence of the admins or the competence of the management.

Any experienced admin should be writing automation. Old-school hands on admin is a thing of the past. Maybe not at a mom & pop site but at a large site -- we have 2200 Linux and UNIX systems, and 8000 Windows machines; Google has over 500k systems -- there's no time to give each individual system tender loving care.

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

Certainly. But the job is changing. Sysadmins with a truckload of experience should be writing code, ansible, puppet, chef, cfengine or whatever else and leave the day-to-day handling of requests for junior staff.

I, for instance, spend most of my time writing code to be run by other less experienced admins.

And, most of the new to the business admins I've met may or may not be able to write shell scripts. Certainly not sed, awk, python, perl, let alone real programming languages. Unlike a decade or two ago, when sysadmins would get their hands dirty, the environment today is sanitized. So yeah, the nature of the business is changing.

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​

Ultimately end-users will perform sysadmin functions through a web-based interface.

And don't forget, with cloud services customers do their own sysadmin. One can spin up a VM, load it with apps and configure it simply through a web interface. All without having to look at a console screen.

The nature of the business has changed. It's changed a lot over the 50 years I've been in it.

 

[gpw928]

The nature of the business has changed. It's changed a lot over the 50 years I've been in it.

I started with Unix in 1983 on a VAX 750, and retired a few years ago from a site that had thousands of Unix/Linux systems with all the automation tools that IBM and RedHat (with the help of Gartner) could manage to sell to the management (and that was a lot).

The system administrators where I worked needed root access because the problems they dealt with required it. If your job does not require root access for (automation of) system building, maintenance, and problem resolution, then you are not a system administrator -- and you should not have root access.

If your VM spins up automatically, works for the tasks you expect, and allows you to tweak things via a console, that's because a system administrator (and maybe some other specialists like applications, database, and network people) designed and pre-configured it.

I think that perhaps we are discussing job titles, rather than anything else.

 

[cy@]

I started with Unix in 1983 on a VAX 750, and retired a few years ago from a site that had thousands of Unix/Linux systems with all the automation tools that IBM and RedHat (with the help of Gartner) could manage to sell to the management (and that was a lot).

The system administrators where I worked needed root access because the problems they dealt with required it. If your job does not require root access for (automation of) system building, maintenance, and problem resolution, then you are not a system administrator -- and you should not have root access.

If your VM spins up automatically, works for the tasks you expect, and allows you to tweak things via a console, that's because a system administrator (and maybe some other specialists like applications, database, and network people) designed and pre-configured it.

I think that perhaps we are discussing job titles, rather than anything else.

Well maybe. We are discussing my concept of how the business should be structured. All I'm saying is, and trying to convince management that, there should be a core group who have root access to deal with the not so common problems. Everyone else in the team should use the automation.

The people who build the automation are probably the people who should have root. Those who do not should probably not.

I am trying to convince management of this. We are only talking.

I have solid reasons for coming to this conclusion.

 

[Jose]

The system administrators where I worked needed root access because the problems they dealt with required it. If your job does not require root access for (automation of) system building, maintenance, and problem resolution, then you are not a system administrator -- and you should not have root access.

I actively resist receiving root access in prod. Partly is because I get the "with great power..." thing, and partly because I like to sleep at night.

Having root in non-prod is an absolute must have for any computer professional worth his salt. Yes, a small and shrinking group. I know.

 

[cy@]

I actively resist receiving root access in prod. Partly is because I get the "with great power..." thing, and partly because I like to sleep at night.

Having root in non-prod is an absolute must have for any computer professional worth his salt. Yes, a small and shrinking group. I know.

Even for those of use who've been doing this for a long time, we all make mistakes. It's not uncommon for people to reboot the wrong server, even with automation. Or perform a change, like patch a server 24 hours before the actual change.

You can't automate away clerical errors but you can automate away some junior doing something stupid, like naming the old and new LUNs in Linux multipath the same name resulting in jumbled filesystems. Seen someone do this before. I had to be called in to fix the mess.

Cowboy mode can result in disaster. This is way giving a root shell to anyone carte blanche is a bad idea, regardless of their title. This one thing irks me about this business: people think they know better resulting in the person having told them that whatever was a bad idea having to clean up messes. Not everyone has the same care and attention when in a root shell. This is how I came to my conclusion about limiting root shell access.

A good example from some 20 years ago: A brand new employee who I had not wanted to hire but my director figured it was a good idea. I left for lunch. This person, with no UNIX experience and not a native English speaker, was attempting to install some new software on a Solaris system. The message he got was:

ld.so: libkrb5.so not found.

He deleted /lib/ld.so. The system became unusable. I came back from lunch. One of my team members was feverishly attempting to recover the system. When I returned from lunch my director called me into his office (I was team lead) demanding how I could let this happen.

I don't know how a person could parse the phrase "ld.so: libkrb5.so not found" to mean let's delete ld.so to fix.

The lessons here are many. For management and for employees.

 

[T-Aoki]

Just one thing to mention.

Not letting any post to do/decide anything, but leting the right person with sufficient skills, experiences and circumspections should be at the post, thus, can decide and do the right thing.

Non-engineer CIO/CTO without sufficient skills, experiences and circumspections is clearly a disaster.

 

[fmc000]

Even for those of use who've been doing this for a long time, we all make mistakes. It's not uncommon for people to reboot the wrong server, even with automation. Or perform a change, like patch a server 24 hours before the actual change.

You can't automate away clerical errors but you can automate away some junior doing something stupid, like naming the old and new LUNs in Linux multipath the same name resulting in jumbled filesystems. Seen someone do this before. I had to be called in to fix the mess.

Cowboy mode can result in disaster. This is way giving a root shell to anyone carte blanche is a bad idea, regardless of their title. This one thing irks me about this business: people think they know better resulting in the person having told them that whatever was a bad idea having to clean up messes. Not everyone has the same care and attention when in a root shell. This is how I came to my conclusion about limiting root shell access.

A good example from some 20 years ago: A brand new employee who I had not wanted to hire but my director figured it was a good idea. I left for lunch. This person, with no UNIX experience and not a native English speaker, was attempting to install some new software on a Solaris system. The message he got was:

ld.so: libkrb5.so not found.

He deleted /lib/ld.so. The system became unusable. I came back from lunch. One of my team members was feverishly attempting to recover the system. When I returned from lunch my director called me into his office (I was team lead) demanding how I could let this happen.

I don't know how a person could parse the phrase "ld.so: libkrb5.so not found" to mean let's delete ld.so to fix.

The lessons here are many. For management and for employees.

When I was consulting for a big Telco firm here in Italy an employee decided that as the root filesystem was filling up on a Solaris E10000 server a good solution would have been to create a new filesystem and move /usr/lib there and link it back under /usr .

I'll let you imagine how much effort it took me and another consultant to recover from the disaster (it was of course a production machine). The top management decided that something needed to be done and, as it was impossibile to discipline the guy because of Italian labour laws, they demoted his manager who of course had no responsability whatsoever.

 

[gpw928]

The people who build the automation are probably the people who should have root. Those who do not should probably not.

Root passwords are not all that different to the problem of allowing physical access to infrastructure.

In a well-managed environment, there will be regular (and rigorous) reviews of those permitted access. There may also be routine monitoring...

I was not being facetious when I suggested that we were discussing job titles.

If you want to restrict access, then I think that the foundational step is to define the access requirements and policies that relate to the various jobs to be done. e.g. if a person does not have the experience and ability to be trusted with a root password, and need that password to execute their routine duties, they should not be called a "system administrator".

Once you have the (correct) job descriptions in place, the rest is easy.

 

[cy@]

When I was consulting for a big Telco firm here in Italy an employee decided that as the root filesystem was filling up on a Solaris E10000 server a good solution would have been to create a new filesystem and move /usr/lib there and link it back under /usr .

I'll let you imagine how much effort it took me and another consultant to recover from the disaster (it was of course a production machine). The top management decided that something needed to be done and, as it was impossibile to discipline the guy because of Italian labour laws, they demoted his manager who of course had no responsability whatsoever.

Yeah, this reminds me of a client of mine about 20-ish years ago. I was on retainer to provide assistance as required. They had just received a new DEC Alpha running Tru64 UNIX. I installed and configured the O/S for them. It was to be used as a web server. After some time their management had decided to promote one of their clerical staff to webmaster. They provided her the root password.

So... she logged in and changed the ownership of all the files on the system to her account, i.e.

chown -R dora /

What a mess that was. They couldn't reinstall as that would result in the loss of all content. I wasn't involved in the recovery but I was told it took weeks to recover the system to a usable state.

 

[Niklo]

Yeah, this reminds me of a client of mine about 20-ish years ago. I was on retainer to provide assistance as required. They had just received a new DEC Alpha running Tru64 UNIX. I installed and configured the O/S for them. It was to be used as a web server. After some time their management had decided to promote one of their clerical staff to webmaster. They provided her the root password.

So... she logged in and changed the ownership of all the files on the system to her account, i.e.

chown -R dora /

What a mess that was. They couldn't reinstall as that would result in the loss of all content. I wasn't involved in the recovery but I was told it took weeks to recover the system to a usable state.

What happened to Dora after she changed the ownership of all the files on the system? Was she fired?

 

[SirDice]

So... she logged in and changed the ownership of all the files on the system to her account

In case you had someone do this on your FreeBSD systems, there are files under /etc/mtree/ you can use to restore permissions (and ownership) of all the files from the base OS.

 

[cy@]

In case you had someone do this on your FreeBSD systems, there are files under /etc/mtree/ you can use to restore permissions (and ownership) of all the files from the base OS.

That's great for the O/S but not application files -- I think they had an Oracle instance on the box -- you still have a lot of work.

If a person uses dump/restore (FreeBSD, Tru64) or ufsdump/ufsrestore (Solaris), one can use the interactive restore setmode subcommand to restore permissions of all files on the system. I've used that before.

Unfortunately for them they hadn't backed the box up even though an 8mm tape drive was hooked up. Backups required some manual effort at the time.

Someone should start a backup/restore thread here.

 

[Niklo]

Thank you for all the comments.
The thread started with the topic "How can I change the root shell to csh". This topic is solved.
I am new to this forum. Are threads marked as "topic solved" and who can set the status to "solved"?
Kind regards,
Roland

 

[nxjoseph]

Thank you for all the comments.
The thread started with the topic "How can I change the root shell to csh". This topic is solved.
I am new to this forum. Are threads marked as "topic solved" and who can set the status to "solved"?
Kind regards,
Roland

You can add the green solved tag to your topic's title, just check for an edit button near the title.

 

[cy@]

What happened to Dora after she changed the ownership of all the files on the system? Was she fired?

Last I heard she ended up working in another part of that organization.

The joke was when anyone made a boneheaded thing they'd say so-and-so "did a Dora." There was a lot of speculation among the tech staff there, which was unfair to her but people's imaginations go wild.

The last time I spoke to the guy who fixed the mess -- he's retired now -- he still spoke of it. People don't forget stuff like that.

On the serious side of the story, it says a lot about protecting one's reputation. Something stupid can ruin one's reputation, where people will be talking about it for years, even decades after the fact.

 

[Jose]

A good example from some 20 years ago: A brand new employee who I had not wanted to hire but my director figured it was a good idea. I left for lunch. This person, with no UNIX experience and not a native English speaker, was attempting to install some new software on a Solaris system. The message he got was:

ld.so: libkrb5.so not found.

He deleted /lib/ld.so. The system became unusable. I came back from lunch. One of my team members was feverishly attempting to recover the system. When I returned from lunch my director called me into his office (I was team lead) demanding how I could let this happen.

More than 20 years ago my shiny new employer handed me a shiny new Sun Ultra 60. I was so excited! But that shell for the root user... lemme install a dynamically-linked bash instead! This rendered the system unbootable, of course. On my very first day. Way to make an impression. I spent the next 10 hours or so in a sweaty pursuit of a bootable Solaris system. I got it eventually, and learned a whole lot in the process. Fortunately no one noticed. In retrospect I've realized most people don't expect much from new employees for at least a week, let alone one day.

When I was consulting for a big Telco firm here in Italy an employee decided that as the root filesystem was filling up on a Solaris E10000 server a good solution would have been to create a new filesystem and move /usr/lib there and link it back under /usr .

I'll let you imagine how much effort it took me and another consultant to recover from the disaster (it was of course a production machine). The top management decided that something needed to be done and, as it was impossibile to discipline the guy because of Italian labour laws, they demoted his manager who of course had no responsability whatsoever.

I had troubles with Solaris before the Ultra 60 incident above (one would think I would've learned...) I was working at a place where we had an Oracle database running on a Sun pizza box. Oracle at the time recommended raw partitions for data storage for maximum performance. I was logged in to that machine for unrelated reasons when I noticed all this free space in unused partitions. That machine was running low on disk, so I went ahead and newfsed those suckers. The Anderson (now Accenture) consultants were not happy with me, even though they probably got some nice billable hours from that event.

We had a Vax farm at the same job that ran MS Mail on top of a MS Lan Manager instance. We were running out of disk space on the cluster (this was very common in the '90s), and I decided I had a solution even though I knew nothing about VMS, and that I would try out my "solution" without telling anyone. Upshot was I caused the Vax cluster to need a reboot, which took several hours of downtime. I still remember going to my boss' office to tell him. I figured I was fired, but at least we could contain the damage if we acted sooner rather than later. His shoulders slumped, and he looked a little older, but he didn't fire me. I still don't know anything about VMS.

 

[Niklo]

You can add the green solved tag to your topic's title, just check for an edit button near the title.

View attachment 21399
View attachment 21400

Hello Joseph,
thank you very much. I am currently using google chrome and I see the "Unwatch" field but there are no three dots "..." with a drop down menu.
My top of the thread look like e.g.:

So I am not able to set one of my current two threads to solved. I currently tested Firefox and it shows the same behaviour. What could be the problem?
I am new to this forum so my posts have to be approved by a moderator before beeing shown. Could this be the reason for not beeing able to see the drop down menu to set the "Closed" option?
Kind regards,
Roland

 

[ralphbsz]

Oracle at the time recommended raw partitions for data storage for maximum performance. I was logged in to that machine for unrelated reasons when I noticed all this free space in unused partitions. That machine was running low on disk, so I went ahead and newfsed those suckers.

I still put a list of all partitions into /etc/fstab, with the entries for partitions without file systems commented out and explaining why they exist.

 

[nxjoseph]

Niklo, You are welcome but I don't know why you can't see it, maybe we should ask to SirDice.

 

[fernandel]

Hello Joseph,
thank you very much. I am currently using google chrome and I see the "Unwatch" field but there are no three dots "..." with a drop down menu.
My top of the thread look like e.g.:
View attachment 21405
So I am not able to set one of my current two threads to solved. I currently tested Firefox and it shows the same behaviour. What could be the problem?
I am new to this forum so my posts have to be approved by a moderator before beeing shown. Could this be the reason for not beeing able to see the drop down menu to set the "Closed" option?
Kind regards,
Roland

 

[SirDice]

I am new to this forum

That's the reason, you still have the "newbie" status. That status will get lifted after 10 posts (you've past that already) and 10 days (6 Jan. only a few days to go) .