In this thread, I received recommendations on how to configure my choice of terminal for my main account (huji) on the Clouds. However, we have not been able to figure out a way to configure the choice of terminal for my tools account (tools.huji). Can you please help me change it to zsh and show me how it is done? I would like to add the documentation to the Wikitech wiki.
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T186108 Allow tool maintainers to set a default shell for a tool account | |||
| Open | None | T426378 Tools may not allow non-interactive commands via 'become' due to dotfile configuration |
Event Timeline
For reference, @Huji successfully set his user shell LDAP preference to zsh, but since both tools-bastion hosts are Ubuntu trusty they do not have the needed chsh.ldap utility. I do not have the needed LDAP permissions to change the tools.huji loginShell attribute. Since I'm not aware of machines with chsh.ldap that Huji, or myself, would have sudo permissions (to sudo -iu tools.huji) I recommended he open this task.
Either chsh.ldap as tools.huji from a debian machine or ldapvi from terbium should be able to solve this (maybe ldapvi -D DN_OF_A_PRIVELEGED_USER will work from any host as well).
From what I see, on a jessie cloud instance, chsh.ldap is from the nslcd-utils package. This package seems to be installed on all jessie and stretch instances during bootstrap. That would be quite a lot of instances on toolforge alone:
root@tools-worker-1027:~# which chsh.ldap /usr/bin/chsh.ldap
However, from what I see /usr/bin/chsh.ldap is a symlink to /usr/share/nslcd-utils/chsh.py, which is a python script and can't suid and do magic tricks like opening privileged ports. I don't understand how it could be theoretically able to modify LDAP data.
@zhuyifei1999 I feel silly for not thinking of the workers. Alas it did not solve the problem
root@tools-worker-1019:~# sudo -niu tools.huji
tools.huji@tools-worker-1019:~$ chsh.ldap -s /usr/bin/zsh tools.huji
LDAP password for tools.huji:
tools.huji@tools-worker-1019:~$ tail /var/log/syslog -n 400|grep nslcd
Jan 31 23:13:37 tools-worker-1019 nslcd[3022]: [a44b5f] <usermod="tools.huji"> uid=tools.huji,ou=people,ou=servicegroups,dc=wikimedia,dc=org: lookup error: Server is unwilling to perform
Jan 31 23:13:37 tools-worker-1019 nslcd[3022]: [a44b5f] <usermod="tools.huji"> uid=tools.huji,ou=people,ou=servicegroups,dc=wikimedia,dc=org: modification failed: Server is unwilling to perform
As far as I can see /usr/bin/chsh.ldap calls nslcd to do the actual LDAP work, but it still depends on LDAP permissions and seems to still be failing due to tool accounts not having an LDAP password set.
It will not be scalable to have default shell changes be handled as a manual process by LDAP admins. Functionality could be added to an end-user interface such as Striker to make this sort of change a self-service operation. The current demand for this feature is very low (1/1938 tools as far as we know today), so I am prioritizing as "lowest".
When bash starts as a login shell, it reads /etc/profile for configuration and then checks for $HOME/.bash_profile, $HOME/.bash_login and $HOME/.profile configuration scripts maintained by the user and executes commands from the first one of these three that is found and is readable. We can take advantage of this to replace the default login shell with the shell of a user/tool's choosing. The $HOME/.bash_profile script will only be evaluated by /bin/bash and additionally only when /bin/bash is invoked as a login shell (first character of argument zero is a -, or started with the --login option). We can even add a second guard so that we only swap the shell when the login shell is an interactive shell (started without non-option arguments and without the -c option with stdout and sterr connected to terminals, or started with the -i option). This can be checked for programmatically by examining the special $- variable exposed to the shell's runtime.
[[ "$-" == *i* ]] && exec /usr/bin/zsh
export SHELL=/usr/bin/zsh
Here is an example of using a tool that has been configured with that magic [[ "$-" == *i* ]] && exec /usr/bin/zsh in $HOME/.bash_profile as well as a few echo messages to let you see when various dotfiles are evaluated:
$ become bd808-test2 * Running /data/project/bd808-test2/.bash_profile * Running /data/project/bd808-test2/.zshrc % exec bash * Running /data/project/bd808-test2/.bashrc $ echo $- himBH $ exec bash --login * Running /data/project/bd808-test2/.bash_profile * Running /data/project/bd808-test2/.zshrc % bash -c 'echo $-' hBc % bash -ic 'echo $-' * Running /data/project/bd808-test2/.bashrc himBHc %