Hi guys,
When I log into my system I get the tc-shell but I should now be getting bash…as that is the default shell defined by my LDAP authentication server (there are no local accounts).
I have a .login and .cshrc for when I used to use tcsh before, and I now have a .profile file for bash.
I’m using SUSE Linux Enterprise 11, how can I get a login to bash? It’s present at /bin/bash and listed in /etc/shells. Do I need to change something on the system itself? I’m an administrator on this machine.
Thanks a lot
Andy
What’s the output of these commands
$ cat /etc/*release*
$ grep passwd /etc/nsswitch.conf
$ echo $0
$ id
$ getent passwd $USER
$ grep ^${USER}: /etc/passwd
$ file $(which bash)
[QUOTE=mikewillis;15053]What’s the output of these commands
[CODE]$ cat /etc/release
a/arb7> cat /etc/release
LSB_VERSION=“core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64”
cat: /etc/lsb-release.d: Is a directory
SUSE Linux Enterprise Desktop 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
SUSE Linux Enterprise Desktop 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
$ grep passwd /etc/nsswitch.conf
a/arb7> grep passwd /etc/nsswitch.conf
passwd: files nis
#passwd: compat
passwd: files ldap
$ echo $0
a/arb7> echo $0
-tcsh
$ id
a/arb7> id
uid=4590(arb7) gid=15109(sh_staff) groups=15109(sh_staff),59011(lamp),100017(ram-fs),100018(ram-fs-x),100107(ram-fs-r)
$ getent passwd $USER
a/arb7> getent passwd $USER
arb7:x:4590:15109:Andy Barnes:/home/a/arb7:/bin/tcsh
$ grep ^${USER}: /etc/passwd
[No output produced]
$ file $(which bash)
a/arb7> file $(which bash)
Illegal variable name.
[/CODE][/QUOTE]
Bash is at /bin/bash
This is a result of getent on the LDAP server:
arb7:x:4590:15109:Andy Barnes:/home/arb7:/bin/bash
Thanks for your help,
Andy
Most curious.
Maybe your previous use of tcsh has been cached. Do you run nscd? On SLED the default setting for passwd is persistent so the cache survives restarts of the service, but the positive-time-to-live defaults to 600 seconds which is only ten minutes. So I can’t see why that would be a problem. Assuming you run nscd you could try as root
$ service nscd stop
$ nscd --invalidate=passwd
$ service nscd start
Similarly for sssd if you run that rather than nscd
$ service sssd stop
$ rm /var/lib/sss/db/*
$ service sssd start
Might be a better way to clear sssd cache than that.
Worth checking /etc/passwd for any users with the same uid as yours, you say there’s no local users and there’s no user with your usercode in there, but given it takes less time to check that than type this, may as well check 
getent on the LDAP server shows your shell as /bin/bash but where is getent on the LDAP server looking for user information?
It should be possible to use ldapsearch on your machine to get information about your usercode, which I would expect to include an attribute that specifies the shell, though the options and arguments will depend on your LDAP server configuration and what’s in /etc/openldap/ldap.conf on your machine. It could be as simple as
$ ldapsearch "(cn=${USER})"
It could be that you need to search using something other than cn, or set cn to something else, or your LDAP server doesn’t allow anonymous bind and you need to give ldapsearch a usercode and password.
Referencing clearing the SSSD cache, the best way is to install the “sssd-tools” package which includes the sss_cache utility, among others, which is used manage cached records in the SSSD cache files. Honestly I feel the YaST default should be to include the sssd-tools package when the sssd package is installed.
Any who, on to how to use the sss_cache utility. It is worthy to note that the utility actually “invalidates” records, it doesn’t delete them. Once the records are invalidated they can be refreshed on the next explicit search by the SSSD or on the next automated refresh cycle by the daemon.
To invalidate the cached record for a user:
sss_cache -u <USER_ID>
To invalidate the cached record for a user in a specific SSSD domain:
sss_cache -u <USER_ID> -d <SSSD_DOMAIN>
To invalidate the cached record for a group:
sss_cache -g <GROUP_NAME>
To invalidate the cached record for a group in a specific SSSD domain:
sss_cache -g <GROUP_NAME> -d <SSSD_DOMAIN>
To invalidate all cached user records:
sss_cache -U
To invalidate all cached group records:
sss_cache -G
To invalidate all cached user and group records in a specific SSSD domain:
sss_cache -UG -d <SSSD_DOMAIN>
Use “man sss_cache” for more information.
Hoping it helps,
– lawrence