|Summary:||bash fails to source either ~/.bashrc or ~/.bash_profile on login|
|Product:||[Fedora] Fedora||Reporter:||Doug Ledford <dledford>|
|Component:||pam_ldap||Assignee:||Orphan Owner <extras-orphan>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|:||1659623 (view as bug list)||Environment:|
|Last Closed:||2018-12-18 15:29:10 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Doug Ledford 2018-12-11 17:06:34 UTC
Description of problem: The bash environment for the user is not getting set properly Version-Release number of selected component (if applicable): bash-4.4.23-5.fc29.x86_64 pam-1.3.1-8.fc29.x86_64 freeipa-client-4.7.0-3.fc29.x86_64 systemd-239-6.git9f3aed1.fc29.x86_64 util-linux-2.32.1-1.fc29.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create at least one local account, and join a freeeipa domain with separate freeipa based accounts 2. Use local home directories instead of automount maps for ipa user home dirs 3. Login to the local user account and the freeipa account from either a text terminal login or by creating gnome-terminals with the login shell option present 4. Local account will process ~/.bash_profile, ipa account will process all of the /etc/profile and /etc/bashrc contents, but will not process any user specific files 5. Login to the local account and the freeipa account with a non-login shell, local account will process ~/.bashrc but ipa account will not (and will have a mostly uninitialized shell with a prompt of "sh-2.4 $") Actual results: Shell does not process any home directory files on the ipa account, in spite of the fact that there is a local home directory and the files are present Expected results: Shell will process home directory bash files: .bashrc, .bash_profile, .bash_logout Additional info: I dumped this on pam_ldap because ldap logins are the only thing effected to my knowledge. But, it could be some other part of the login process that's failing. I don't really have a good trace (I don't know what options to enable where in order to debug this), but am willing to create one if you'll give me instructions on how to trace the login process to find the failure.
Comment 1 Doug Ledford 2018-12-18 15:29:10 UTC
From the RHEL8 bug: Yep, that solved the problem. I didn't know you had to specify the shell as bash for it to process .bash_profile and .bashrc. I'll change the default shell on the ipa server and update the users. Thanks! Status: NEW → CLOSED Last Closed: 2018-12-18 15:28:13 Resolution: --- → NOTABUG [tag] [reply] [−] Private Comment 9 Sumit Bose 2018-12-18 06:22:25 UTC (In reply to Doug Ledford from comment #5) > [dledford@haswell-e ~]$ getent passwd dledford > dledford:*:2217:2217:Doug Ledford:/home/dledford:/bin/sh > Is there any change if you replace '/bin/sh' with '/bin/bash' ? > That's all correct. > > [dledford@haswell-e ~]$ ls -ld . > drwx--x---+ 44 dledford dledford 4096 Dec 16 13:58 . > > > And just to double check the SELinux context: > > [dledford@haswell-e ~]$ ls -ldZ . > drwx--x---+ 44 dledford dledford unconfined_u:object_r:user_home_dir_t:s0 > 4096 Dec 16 13:58 . > > What journal info would you like?