Page MenuHomePhabricator

Allow tool maintainers to set a default shell for a tool account
Open, LowestPublic

Description

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.

Event Timeline

Chicocvenancio renamed this task from Setting the terminal choice for the tools account to Changing shell preference tools.huji account.Jan 31 2018, 2:34 PM
Chicocvenancio triaged this task as Low priority.
Chicocvenancio subscribed.

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.

bd808 lowered the priority of this task from Low to Lowest.Feb 1 2018, 4:53 PM
bd808 edited projects, added: Striker; removed: Toolforge, cloud-services-team (Kanban).
bd808 subscribed.

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.

$HOME/.bash_profile
[[ "$-" == *i* ]] && exec /usr/bin/zsh
$HOME/.zshrc
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
%
bd808 renamed this task from Changing shell preference tools.huji account to Allow tool maintainers to set a default shell for a tool account.Aug 31 2018, 12:16 AM