Hi Adam, first thanks for your long and comprehensive answer. Sorry for not providing this information in the first place as I did not think it makes any difference but I'm using the embedded version with NanoBSD.
On Thu, Dec 02, 2010 at 01:16:09AM -0600, Adam Thompson wrote: > /etc/rc.initial, line 114 (on my build, anyway). For whatever reason, > choosing option 8 invokes tcsh(1) directly. I guess this was meant as method to fix things deep inside? > Presumably you could change > this, but I don't know what else this could break... *probably* nothing > except future updates, or more likely you'd have to re-change the file > after every update. Yes I already made such experiences... > > Alternatively, you might try changing the login shell for *admin*, not > root. Hmmmm > I believe that having multiple users with the same UID but > different login shells officially results in "undefined" behaviour, but > obviously it works with /etc/passwd under FreeBSD. I can't tell if this > was the original intent (does this qualify as "Stupid passwd(5) Tricks" à > la Letterman?) or not, but there's root, toor, and admin, all with UID 0. > Obviously the last one in the file wins. That does not really explain the behaviour I experienced yet: As admin has /etc/rc.initial as it's login shell vs root with /bin/sh, I looked at how /etc/rc.initial get involved for root. This is done via /root/.profile which in case of an interactive shell starts /etc/rc.initial. Renaming /root/.profile to /root/.profile_ORIG resulted in root logging in into a /bin/sh environment. I could "fix" this by adding a /bin/tcsh to /root/.profile but as this means changes to the image I was somewhat reluctant to start walking this way... > > It appears that "root" is logged in automatically (well, sort of... "root" > logs in but "admin"'s data is used for getpwent(3) calls, whatever...) by > adding "al=root" to the terminal definition in (iirc) /etc/gettytab. But that would circumvent the usage of admin somehow ;-). > > This whole setup appears to be... not "fragile", exactly, more like "no > user-serviceable parts inside". Yes seems so... > Pending one of the devs chiming in, I'd > guess editing /etc/rc.initial is the least likely option to break > anything. Well after my tries I somehow get the idea that /etc/passwd gets replaced on every reboot... maybe any of the developers can comment on this? > > And yeah, having tcsh as the default shell is annoying, Not really, back in 2000 I used to work with tcsh often enough to appreciate it's features and as no /bin/bash is available it's a solid alternative. > but really - why > are you spending so much time at the CLI on your *firewall* that you feel > you have to change it? Because my company is planning to replace our current monowalls with some other solution and we are trying to make this as efficient as possible... > > FWIW, I'm looking at the installable version, not the embedded version, so > YMMV. Hmmm I'm not familiar enough with *BSD to comment on the differences but thanks for your help. > > -Adam Thompson > athom...@athompso.net Kind regards Harald Jenny > > > > -----Original Message----- > > From: Harald Jenny [mailto:har...@a-little-linux-box.at] > > Sent: Wednesday, December 01, 2010 16:08 > > To: discussion@pfsense.com > > Subject: [pfSense-discussion] pfSense 2.0 ssh login question > > > > Dear list members, > > > > I'm currently playing with pfSense 2.0 an was wondering how to > > change the > > default shell for the root login - apperently just using chsh on > > the rw mounted > > cf is not enough to do change shell from /bin/sh to /bin/tcsh. What > > did I miss? > > > > Kind regards > > Harald Jenny > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com > > For additional commands, e-mail: discussion-h...@pfsense.com > > > > Commercial support available - https://portal.pfsense.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com > For additional commands, e-mail: discussion-h...@pfsense.com > > Commercial support available - https://portal.pfsense.org --------------------------------------------------------------------- To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com For additional commands, e-mail: discussion-h...@pfsense.com Commercial support available - https://portal.pfsense.org