You are not logged in.

#1 2016-08-16 02:04:46

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

[SOLVED] bl-user-setup causes login failure for Active Directory

I've been setting up a pilot BL system, with a view to deploying several integrated with Active Directory.

By following this guide (with some minor tweaks, like pointing to /usr/share/bunsen/skel ) I can join the machines to my domain, AD users can login, have their home directories created, and domain admins get sudo rights.

The issue is that in order to login AD users must ctrl-alt-f2 to a tty, login, and issue startx manually.  Trying to login from the normal login screen fails with no visible error, just returns you to the login screen.  I've no idea what logs to look at for errors, or how to look at them under systemd, bring back plain text!

Google has been unhelpful on this occasion, with most of the results telling me to set

greeter-show-manual-login=true

which makes no difference.

I've also found references to setting override_homedir in sssd.conf, which I've also done after visiting

man sssd.conf

to no avail, I'm a bit lost tbh, much more comfortable troubleshooting windows as a general rule.

Any useful pointers would be appreciated, I'm probably missing something obvious, sadly I've only been documenting the steps that did work as I went along, not those that didn't, so it's hard to enumerate all the settings and tweaks I've tried.

Last edited by Bearded_Blunder (2016-09-22 14:25:26)


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#2 2016-08-16 07:55:48

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Bearded_Blunder wrote:

I've no idea what logs to look at for errors, or how to look at them under systemd, bring back plain text!

The systemd logs are stored in binary but can be extracted with the `strings` command and then parsed with the usual GNU suspects (`awk` ftw!).

Alternatively, use this method:
http://unix.stackexchange.com/questions … her-system
smile

In respect of specific errors from LightDM, have a look in ~/.xsession-errors, /var/log/lightdm/lightdm.log (and other files in that folder) and also check /var/log/Xorg.0.log


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#3 2016-08-16 11:08:21

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Thanks for the pointers, /var/log/lightdm/lightdm.log seems to show authentication is working:

[+330.53s] DEBUG: Activating VT 7
[+330.53s] DEBUG: Activating login1 session c4
[+330.66s] DEBUG: Session pid=852: Greeter connected version=1.10.3
[+331.04s] DEBUG: Session pid=852: Greeter start authentication
[+331.05s] DEBUG: Session pid=873: Started with service 'lightdm', username '(null)'
[+331.07s] DEBUG: Session pid=873: Got 1 message(s) from PAM
[+331.07s] DEBUG: Session pid=852: Prompt greeter with 1 message(s)
[+346.13s] DEBUG: Session pid=852: Greeter start authentication for ADuser@localdomain.local
[+346.13s] DEBUG: Session pid=873: Sending SIGTERM
[+346.14s] DEBUG: Session pid=875: Started with service 'lightdm', username 'ADuser@localdomain.local'
[+346.14s] DEBUG: Session pid=873: Terminated with signal 15
[+346.14s] DEBUG: Session: Failed during authentication
[+346.14s] DEBUG: Seat: Session stopped
[+346.18s] DEBUG: Session pid=875: Got 1 message(s) from PAM
[+346.18s] DEBUG: Session pid=852: Prompt greeter with 1 message(s)
[+349.79s] DEBUG: Session pid=852: Continue authentication
[+349.97s] DEBUG: Session pid=875: Authentication complete with return value 0: Success
[+349.97s] DEBUG: Session pid=852: Authenticate result for user ADuser@localdomain.local: Success
[+349.97s] DEBUG: Session pid=852: User ADuser@localdomain.local authorized
[+349.97s] DEBUG: Session pid=852: Greeter sets language en_GB.utf8
[+349.98s] DEBUG: Session pid=852: Greeter requests session lightdm-xsession
[+349.98s] DEBUG: Seat: Stopping greeter; display server will be re-used for user session
[+349.98s] DEBUG: Session pid=852: Sending SIGTERM
[+350.01s] DEBUG: Session pid=852: Greeter closed communication channel
[+350.02s] DEBUG: Session pid=852: Exited with return value 0
[+350.02s] DEBUG: Seat: Session stopped
[+350.02s] DEBUG: Seat: Greeter stopped, running session
[+350.02s] DEBUG: Launching process 884: /usr/lib/bunsen/configs/bl-user-setup
[+350.03s] DEBUG: Process 884 exited with return value 1
[+350.03s] DEBUG: Seat: Exit status of /usr/lib/bunsen/configs/bl-user-setup: 1
[+350.03s] DEBUG: Seat: Switching to greeter due to failed setup script
[+350.03s] DEBUG: Seat: Creating greeter session
[+350.04s] DEBUG: Session pid=885: Started with service 'lightdm-greeter', username 'lightdm'
[+350.05s] DEBUG: Session pid=875: Exited with return value 0
[+350.05s] DEBUG: Seat: Session stopped
[+350.09s] DEBUG: Session pid=885: Authentication complete with return value 0: Success
[+350.09s] DEBUG: Seat: Session authenticated, running command
[+350.09s] DEBUG: Session pid=885: Running command /usr/sbin/lightdm-gtk-greeter
[+350.10s] DEBUG: Creating shared data directory /var/lib/lightdm/data/lightdm
[+350.10s] DEBUG: Session pid=885: Logging to /var/log/lightdm/x-0-greeter.log

and  that /usr/lib/bunsen/configs/bl-user-setup has some problem around timestamp [+350.02s] to [+350.03s].
Looking at that:

#!/bin/bash
# BunsenLabs User Set-up

# USER="$1" USER is exported by lightdm
[[ "$USER" = root || ! -d /home/"$USER" ]] && { echo "$0: variable USER has not been set correctly." >&2; exit 1;}

[ -f "/home/$USER/.config/bunsen/bl-setup" ] && exit 0

bkp_sfx="~$( date +%FT%T )~"

rsync -rltb --suffix="$bkp_sfx" --safe-links /usr/share/bunsen/skel/ /home/$USER

for i in "/home/$USER/.gtk-bookmarks" "/home/$USER/.config/nitrogen/nitrogen.cfg"
do
    [ -f "${i}.template" ] || continue
    sed --in-place "s/%USERNAME%/$USER/g" "${i}.template"
    if [ -f "$i" ]
    then
        if diff -BEbZ "$i" "${i}.template" >/dev/null
        then
            rm "${i}.template"
        else
            mv "$i" "${i}${bkp_sfx}"
            mv "${i}.template" "$i"
        fi
    else
        mv "${i}.template" "$i"
    fi
done

ln -sTf /usr/share/images/bunsen/wallpapers "/home/$USER/Pictures/wallpapers/bunsen"

mkdir -p "/home/$USER/.config/bunsen" # this should already exist
touch "/home/$USER/.config/bunsen/bl-setup"

chown -R "$USER":"$USER" "/home/$USER"

exit

I see the only place it exits with a status of 1 is right at the start

[[ "$USER" = root || ! -d /home/"$USER" ]] && { echo "$0: variable USER has not been set correctly." >&2; exit 1;}

I'm just unsure how to check what lightdm is exporting to the script, and consequently why this check is failing. If indeed that is the problem.

Looking in ~/.xsession-errors would only be useful for the ADuser's home, and at least in the case of a first login, neither exists nor gets created, except by logging in from a tty.  I do notice for a user who has logged in via tty, all references to that user are entirely lower case as in "aduser" rather than "ADuser".

I might try creating an entirely lower case user "test@localdomain.local" though most of my user accounts are in the form Windows (and users) like Firstname.Lastname@localdomain.local

[edit]Made no difference being entirely lower case [/edit]

Last edited by Bearded_Blunder (2016-08-16 11:21:02)


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#4 2016-08-16 11:44:07

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

See https://wiki.archlinux.org/index.php/Ac … ntegration
esp. the section about PAM setup - which enables you to create a 'link' between user name and user file structure, which is what is missing in your setup, I surmise.

I am not familiar with AD, so can't give you more info.

Offline

#5 2016-08-16 12:56:02

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

xaos52 wrote:

See https://wiki.archlinux.org/index.php/Ac … ntegration
esp. the section about PAM setup - which enables you to create a 'link' between user name and user file structure, which is what is missing in your setup, I surmise.

I am not familiar with AD, so can't give you more info.

If I try following that I'll need to start over from the beginning, am using realmd & sssd, the archwiki article linked refers to a completely different method using winbind, akin to telling someone asking "Why is Firefox not loading <insert url>?"
"Because you're not using Google Chrome,  Here's how you set that up." I may yet try that, but it's a lot of pain without solving why realmd & sssd aren't cutting it, since I'd be using something else.

Logging in per-se isn't failing, AD users can login (from a tty) and startx from there, their home directories get created if it's the first login, and "everything works as expected" complete with all the other BL features.

They just can't through the lightdm greeter.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#6 2016-08-16 19:31:43

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

The login managers of GNOME and KDE (GDM and KDM) have been extended to allow the handling of AD domain login.

http://doc.opensuse.org/documentation/h … ty.ad.html

This would suggest that perhaps LightDM doesn't support AD integration.

Can you try GDM to confirm this?

sudo apt-get install --no-install-recommends gdm3
sudo dpkg-reconfigure gdm3

To change back to LightDM, use:

sudo dpkg-reconfigure lightdm

“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#7 2016-08-16 23:20:59

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Wow 91 newly installed, even with "--no-install-recommends", this allows me to confirm gdm3 doesn't like Bunesen...

beardy@bunsen-base:~$ sudo dpkg-reconfigure gdm3
[sudo] password for beardy: 
Job for gdm.service failed. See 'systemctl status gdm.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript gdm3, action "reload" failed.
beardy@bunsen-base:~$ 

so looking at those:

beardy@bunsen-base:~$ sudo systemctl status gdm.service
● gdm.service - GNOME Display Manager
   Loaded: loaded (/lib/systemd/system/gdm.service; enabled)
   Active: inactive (dead)

Aug 16 23:54:35 bunsen-base systemd[1]: Unit gdm.service cannot be reloaded because it is inactive.
Aug 16 23:56:11 bunsen-base systemd[1]: Unit gdm.service cannot be reloaded because it is inactive.
beardy@bunsen-base:~$ 

and

-- Logs begin at Tue 2016-08-16 23:49:26 BST, end at Wed 2016-08-17 00:03:16 BST. --
Aug 16 23:55:41 bunsen-base sudo[3428]: beardy : TTY=pts/0 ; PWD=/home/beardy ; USER=root ; COMMAND=/usr/sbin/dpkg-reconfigure gdm3
Aug 16 23:55:41 bunsen-base sudo[3428]: pam_unix(sudo:session): session opened for user root by beardy(uid=0)
Aug 16 23:56:11 bunsen-base systemd[1]: Unit gdm.service cannot be reloaded because it is inactive.
Aug 16 23:56:12 bunsen-base sudo[3428]: pam_unix(sudo:session): session closed for user root
Aug 17 00:03:05 bunsen-base sudo[3665]: beardy : problem with defaults entries ; TTY=pts/2 ; PWD=/home/beardy ;
Aug 17 00:03:08 bunsen-base sudo[3665]: pam_unix(sudo:auth): authentication failure; logname=beardy uid=1000 euid=0 tty=/dev/pts/2 ruser=beardy
Aug 17 00:03:08 bunsen-base sudo[3665]: pam_sss(sudo:auth): authentication failure; logname=beardy uid=1000 euid=0 tty=/dev/pts/2 ruser=beardy
Aug 17 00:03:08 bunsen-base sudo[3665]: pam_sss(sudo:auth): received for user beardy: 10 (User not known to the underlying authentication mo

Even with a reboot, still get the lightdm login screen, since this is a disposeable install (easily recreated), I might apt-get remove lightdm, see if that makes it use gdm3!


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#8 2016-08-17 07:20:23

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

I have just tried this on my BL system (apologies for not doing that first btw) and although the same error messages are displayed, a reboot takes me to the GDM login screen.

I don't know why that doesn't work for you hmm

What is the output of:

ls -l /etc/systemd/system/display-manager.service

“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#9 2016-08-21 00:16:33

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Sorry it's taken a while to get back, life intervening, had to leave it for a while, on booting back up, GDM came up, and works as expected for AD users.

Interestingly, on reverting to lightdm, with GDM installed, that also then works, I've had no time to investigate why that would be though, but evidently lightdm *can* work, with whatever was changed by GDM in place... be that something it pulled in, or some config change, just had no time to try to isolate what.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#10 2016-08-21 06:21:02

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

It is likely a full reboot would be required, even with a newer kernel, because you need to reload PAM. Also, check to see if accountsservice got pulled in. That would be my first guess.

Offline

#11 2016-08-21 14:21:28

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

We could check the autostarted programs and see what is different from a stock install:

/usr/lib/x86_64-linux-gnu/openbox-xdg-autostart --list

@B_B: I have marked the thread [SOLVED], you can do this yourself next time by editing the title wink


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#12 2016-08-21 16:47:10

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Head_on_a_Stick wrote:

We could check the autostarted programs and see what is different from a stock install:

/usr/lib/x86_64-linux-gnu/openbox-xdg-autostart --list

I shall (when I get free time, I'm currently subject to lots of interruptions, and have a guest in the house so time is limited) be looking into those or at least issue the equivalent for a 32 bit system, along with what GDM pulled in that may actually point me to the proper solution accountsservice looks a likely candidate, since GDM pulls that in, and it's only a suggests for lightdm, and many thanks @tknomanzr for the pointer smile

Head_on_a_Stick wrote:

@B_B: I have marked the thread [SOLVED], you can do this yourself next time by editing the title wink

@HoaS My intention was to do so, once I'd identified the real root of the issue, I do know how, and I also know it's considered bad form not to on this board.

Currently installing GDM switching to it and then back is more of a workaround than a fix as such..  Meantime, I shall edit my first post again to reflect this by saying [WORKAROUND]. Maybe I should have added something to this effect at my last visit, since I have a method that "works" even if it requires building on an extra unused metaphorical lobby.

[SOLVED] is better applied when we have a precise solution, something I hope to have in due course which I'll then report and do the edit for at that time.

Sorry to be such a pedantic old cuss.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#13 2016-08-21 17:18:27

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Bearded_Blunder wrote:

@HoaS My intention was to do so, once I'd identified the real root of the issue, I do know how, and I also know it's considered bad form not to on this board.

Currently installing GDM switching to it and then back is more of a workaround than a fix as such..  Meantime, I shall edit my first post again to reflect this by saying [WORKAROUND]. Maybe I should have added something to this effect at my last visit, since I have a method that "works" even if it requires building on an extra unused metaphorical lobby.

[SOLVED] is better applied when we have a precise solution, something I hope to have in due course which I'll then report and do the edit for at that time.

I disagree.

LightDM does not appear to support AD logins and so the solution is to use a display manager that does.

As such, I consider that this thread is indeed [SOLVED] and I am re-marking it as such in order to aid others who may have this problem.

I see no point using a nonsense tag for the thread as this will decrease SEO for the problem in hand.

I have closed the thread for now, if you wish to investigate further please PM me with the XDG autostart list and I will re-open the thread.

EDIT: Thread re-opened after further consideration.

Last edited by Head_on_a_Stick (2016-08-21 20:06:49)


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#14 2016-08-24 03:34:53

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

In order to test your position, I have done the following.
1. A Jessie netinstall, at tasksel, I deselected everything except standard system utils
2. Installed xorg
3. Installed lxde-core
This gave me a very basic system with tty login and startx manually. No dm installed or configured.
4. I then installed lightdm to give myself a graphical login.

This was my test system.
I then installed realmd adcli  and sssd and joined the domain the exact same way I did with bunsen

I then appended

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

to the file /etc/pam.d/common-session
in the exact same way I had appended

session required pam_mkhomedir.so skel=/usr/share/bunsen/skel/ umask=0022

to the same file when trying this in bunsen.

I also (though I don't think it's relevent) created a file named domain_admins in /etc/sudoers.d/ containing

%domain\ admins@localdomain.local ALL=(ALL:ALL) ALL

to give domain admins local sudo rights on login (domain name changed to something generic).

At this point logging in as an AD domain user works perfectly in the test system, and domain admins indeed get sudo rights.

In this test setup, AD logins work perfectly.

I believe this shows that though there is an issue with graphical logins for AD users in bunsen, the cause is not LightDM.  Which I already suspected was the case, as switching back to LightDM after installing and using GDM once allowed such logins using it, which indicated to me that it should work just fine, if the config, and needed deps for AD logins are correct.

Incidentally this also eliminated the accountsservice package as the cause, as it's not present on the working lxde-core test system.

In light of the above testing, I'm editing the thread title to "Something causes graphical login for Active Directory users to fail"

Personally I don't see what difference a tag or otherwise makes at this stage, since the problem and subsequent solution is only relevant to bunsen, and not wider searches, nor do I believe "workaround" to be nonsense, and an (admittedly effective) workaround is all we have at the moment. I'm still looking to find a clean solution.

Unfortunately, I'm still at somewhat of a loss as to what the cause is......

As requested, output from

/usr/lib/i386-linux-gnu/openbox-xdg-autostart --list

on the machine with GDM3 installed and consequently working logins:

[ ] AT-SPI D-Bus Bus
	  File: /etc/xdg/autostart/at-spi-dbus-bus.desktop
	  Executes: /usr/lib/at-spi2-core/at-spi-bus-launcher --launch-immediately
	* Excluded by: OnlyShowIn (GNOME, Unity)

[ ] Secret Storage Service
	  File: /etc/xdg/autostart/gnome-keyring-secrets.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=secrets
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

[ ] GPG Password Agent
	  File: /etc/xdg/autostart/gnome-keyring-gpg.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=gpg
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

[ ] PolicyKit Authentication Agent
	  File: /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop
	  Executes: /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
	* Excluded by: OnlyShowIn (GNOME, XFCE, Unity)

[*] Network
	  File: /etc/xdg/autostart/nm-applet.desktop
	  Executes: nm-applet

[ ] PulseAudio Sound System KDE Routing Policy
	  File: /etc/xdg/autostart/pulseaudio-kde.desktop
	  Executes: start-pulseaudio-kde
	* Excluded by: OnlyShowIn (KDE)

[*] Screen Locker
	  File: /etc/xdg/autostart/light-locker.desktop
	  Executes: light-locker

[ ] GSettings Data Conversion
	  File: /etc/xdg/autostart/gsettings-data-convert.desktop
	  Executes: gsettings-data-convert
	* Excluded by: OnlyShowIn (GNOME, Unity)

[*] PulseAudio Sound System
	  File: /etc/xdg/autostart/pulseaudio.desktop
	  Executes: start-pulseaudio-x11

[*] Power Manager
	  File: /etc/xdg/autostart/xfce4-power-manager.desktop
	  Executes: xfce4-power-manager

[ ] SSH Key Agent
	  File: /etc/xdg/autostart/gnome-keyring-ssh.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=ssh
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

[ ] ClipIt
	  File: /etc/xdg/autostart/clipit-startup.desktop
	  Executes: clipit
	* Excluded by: OnlyShowIn (GNOME, XFCE, LXDE, Unity)

[ ] XFCE Volume Daemon
	  File: /etc/xdg/autostart/xfce4-volumed.desktop
	  Executes: xfce4-volumed
	* Excluded by: OnlyShowIn (XFCE)

[ ] Certificate and Key Storage
	  File: /etc/xdg/autostart/gnome-keyring-pkcs11.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=pkcs11
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

I can't compare to a default system right now, as I nuked the non-working one for the test described at the start of this post, but I also don't see anything that looks a likely candidate to be different.

Last edited by Bearded_Blunder (2016-08-24 03:37:19)


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#15 2016-08-24 06:56:45

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Thanks for the detailed update smile

The autostart stuff looks normal so that theory is nonsense.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#16 2016-08-24 09:14:09

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

I now have a theory, unfortunately owing to commitments, I may not have time to test it for a couple of days, if I'm correct in where the issue lies, then logging in from a tty or switching DM only partially solves the issue, in that AD users get logged on, with an unconfigured home dir, the clues are in post #3, in neither of these cases does /usr/lib/bunsen/configs/bl-user-setup get run.

I never did much testing of a system logged onto that way beyond seeing that openbox tint2 conky etc. came up, so that's entirely possible.

If I'm correct bl-user-setup either needs a rework to cope with the fact pam_mkhomedir.so creates /home/domain.tld/$USER for active directory logons rather than /home/$USER which it's expecting for local users, and thus exits with a status of 1 aborting the logon. Again clues in post #3

[+350.02s] DEBUG: Seat: Greeter stopped, running session
[+350.02s] DEBUG: Launching process 884: /usr/lib/bunsen/configs/bl-user-setup
[+350.03s] DEBUG: Process 884 exited with return value 1
[+350.03s] DEBUG: Seat: Exit status of /usr/lib/bunsen/configs/bl-user-setup: 1
[+350.03s] DEBUG: Seat: Switching to greeter due to failed setup script

Or possibly better, needs running instead (with suitable edits) from ~/.config/openbox/autostart which would have the advantage of making it DM agnostic.  It currently depends on LightDM or manually adding to the config for any replacement DM.  If so added, I suspect AD logon would then also break for GDM3.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#17 2016-08-25 03:04:30

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,713
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Hi B_B as the writer of bl-user-setup I'm interested in this, though I am not familiar with AD either.

LightDM should be setting USER to the name of the user logging in, and exporting it to bl-user-setup. This works in normal cases. If HOME was also available to bl-user-setup and set correctly to /home/$USER or /home/domain.tld/$USER respectively, then it would be an easy fix. I don't have time to test this right now, however.

Unfortunately, while running bl-user-setup as the user, after login, is an attractive option, if it hasn't yet been run then ~/.config/openbox/autostart, if it exists, will be the generic openbox version. We'd have to call the user setup script from some file that exists independently of bl-user-setup having been run...


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#18 2016-08-25 08:12:53

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,713
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

update: Test confirmed that HOME is available at the time bl-user-setup is run. On my system it's set to /home/john
Now, whether on your setup it gets set to /home/domain.tld/$USER, and whether that is a desirable place for the files in skel to be copied to, are things you will have to check.

Anyway, you could try editing /usr/lib/bunsen/configs/bl-user-setup, substituting "$HOME" for every occurrence of "/home/$USER" and see if that fixes the issue. If it does, we might be able to release an upgraded bl-user-setup (after making sure we've got corner-cases covered).

btw I've just spotted an unquoted variable in bl-user-setup that will need fixing anyway.  yikes

Last edited by johnraff (2016-08-25 08:17:48)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#19 2016-08-25 21:17:22

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Woke up, going to take a look later, got pounced on to do other things. Need to reinstall my test system, I was tired last time I did things on it and forgot to snapshot it before running stuff (and messing it up), now I can't simply revert to before having any AD user accounts and other modified stuff on there  ops

However I can already confirm that, on my setup, the line

session required pam_mkhomedir.so skel=/usr/share/bunsen/skel/ umask=0022

added to /etc/pam.d/common-session already takes care of copying skel and the ~/.config/openbox/autostart runs.  I have (had before I broke stuff) it setting the screen resolution for AD users already by editing it and adding a copy of my modified .screenlayout folder from the local user created during setup in /usr/share/bunsen/skel/ and editing autostart in skel. It's the customisations done by bl-user-setup that aren't at present happening, as the only way I've been able to log them on is by commenting out the line calling the bl-user-setup script from LightDM, switching to a tty to login, or switching DM.

johnraff wrote:

Now, whether on your setup it gets set to /home/domain.tld/$USER, and whether that is a desirable place for the files in skel to be copied to, are things you will have to check.

I suspect putting it anywhere other than that would cause issues as

$ sudo getent passwd User@domain.tld

returns a line specifying that home is located at /home/domain.tld/user for them, that's the first check I do after joining the machine to AD to check it joined properly and capable of getting authentication information from AD I'm not certain how I'd check what bl-user-setup sees before anyone is logged on though, I'd be surprised if it didn't report the identical info as getent passwd. I'm given to understand that it's possible to modify that location on the AD side specifying different things for different OUs, but I've not found a tutorial for how nor do I wish to, it seems it's the accepted default place for AD users to go on linux systems. AD users can also use a custom skel specific to them simply by specifying that instead of the local users' one in /etc/pam.d/common-session, although in that case one obviously has to create a custom skel for them somewhere.

johnraff wrote:

Anyway, you could try editing /usr/lib/bunsen/configs/bl-user-setup, substituting "$HOME" for every occurrence of "/home/$USER" and see if that fixes the issue. If it does, we might be able to release an upgraded bl-user-setup (after making sure we've got corner-cases covered)

I was, before I made a silly error and lost my efforts, already editing bl-user-setup to see if I could get it going, the silly error being why I went to bed, and now need to reinstall before continuing. I was intending at the time to call it from autostart, once I had it working in a terminal as the logged on user where I can watch the output. doing so from LightDM will involve me making the check right at the start pass for both my local user, and AD users, which makes my head hurt to do properly rather than simply commenting it out, I find editing bash scripts a slow process, as unlike DOS.bat and Windows.cmd scripts, I have to google virtually everything for the bash equivalent of the DOS line, and doing anything with sed usually takes me hours of research combined with multiple non-working versions.

Since I have to start over anyhow, I'll try it your way first, though I think it would work after logon running as the user, though perhaps not for new *local* accounts.  If your suggestion does work, feel free to define what "corner cases" you want covered, I don't mind joining a machine to AD & creating some test users to check things out.

Irrelevent aside wrote:

n00b question, since bunsen uses a custom skel, would specifying it in /etc/adduser.conf instead of the default SKEL=/etc/skel entry in there get bunsen's skel copied without relying on bl-user-setup to do the copy for local accounts, and use the script just for the edits since it would then autostart if called in a similar fashion to bl-welcome? SKEL= wouldn't be a configurable setting if it wasn't envisaged that changing it might be useful.

I foresee people switching DM, or disabling LightDM to use text based login, then wondering months later why adding a user is broken or gets a broken wallpaper chooser etc., and not realising the two things could be related. Sure they'll get the answer if they ask here, or search diligently enough, but better if they never need to ask the question.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#20 2016-08-26 02:19:25

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,713
Website

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

About the skel location:
http://crunchbang.org/forums/viewtopic.php?id=39678
One reason for the switch was precisely so "lean" users could be created without all that config.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#21 2016-08-29 03:30:01

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Update:
I haven't abandoned this, still working on things, have something here that appears to work for AD users, need to do more testing for local ones, and a few other corner cases I spotted where things appear to have issues.

Sadly I haven't found a method to call bl-user-setup from LightDM that plays nicely, AD user accounts get created by an entry in /etc/pam.d/common-session but PAM is a procrastinator, and doesn't create their $HOME till after the DM gives the OK, even if the location it will be created is in the environment at that point, so simply substituting $HOME for /home/$USER in the script doesn't cut it, first thing that happens is the script looks for it, finds it's not there yet and quits.

However, although slow, I am making progress towards a solution, it currently needs some refinements, and pounding on in a VM or two to determine what ways I or other users can break it.  The current iteration gets called after login from autostart, but still allows easy creation of a "barebones" user, and touches no files in /etc/skel

Also my work in bash is embarrassing, looking like the illegitimate offspring of Windows autoscript (AutoIT) and batch-files, which are what I'm much more used to writing.

I hesitate to post the current state of a "work-in-progress" though, at least till I have something I've not found easy or likely ways to break.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#22 2016-09-22 14:22:30

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

## Method 1 ##

Running as user, post login (my personal preference)

What I do to make this work:
Configure adduser
Configure useradd
Symlink the revised config files
Remove call to user setup script from LightDM
Add call to new user setup script to /usr/share/bunsen/skel/.config/openbox/autostart
Provide revised and renamed user-setup script

A reboot, or other measures to cause LightDM to reload its config, seems to be required between making these changes and logging in as a newly created user, else the new login fails.

# Details:
adduser:
Copy /etc/adduser.conf to /etc/adduser.stock.debian
Edit /etc/adduser.conf as follows:
Change SKEL=/etc/skel to SKEL=/usr/share/bunsen/skel
Uncomment and change EXTRA_GROUPS to read EXTRA_GROUPS="dip cdrom floppy audio video plugdev lp"
Uncomment #ADD_EXTRA_GROUPS=1
Copy /etc/adduser.conf to /etc/adduser.bunsen.user
edit EXTRA_GROUPS again adding sudo and netdev to the listed groups
Rename /etc/adduser.conf to /etc/adduser.bunsen.admin
Make /etc/adduser.conf a symlink to /etc/adduser.bunsen.user

useradd:
Copy /etc/default/useradd to /etc/default/useradd.debian
Edit /etc/default/useradd as follows:
Uncomment the SKEL= key and change to SKEL=/usr/share/bunsen/skel
Rename /etc/default/useradd to /etc/default/useradd.bunsen
Make /etc/default/useradd a symlink to /etc/default/useradd.bunsen

LightDM:
Edit the session_setup_script key in /etc/lightdm/lightdm.conf.bunsen
from
session-setup-script=/usr/lib/bunsen/configs/bl-user-setup
to the default value
#session-setup-script=

bl-user-setup
Delete /usr/lib/bunsen/configs/bl-user-setup
Create instead /usr/lib/bunsen/configs/bl-new-user-setup containing this:

#!/bin/bash
# Modified BunsenLabs User Set-up

# exit immediately if previously run
[ -f "$HOME/.config/bunsen/bl-setup" ] && exit 0

# Check for running on a non-bunsen $HOME (e.g. in a terminal, or by editing start-up files)
if [[ ! -d "$HOME/.config/bunsen" ]]; then
	# Post Error
	echo "Error: Script cannot update a non-bunsen account. Exiting."
	exit 1
fi

bkp_sfx="~$( date +%FT%T )~"

# Set correct path in ~/.gtk-bookmarks and ~/.config/nitrogen/nitrogen.cfg
# For clarity, these should probably be updated in /usr/share/bunsen/skel
# such that sed replaces %HOMEDIR% in this loop
for i in "$HOME/.gtk-bookmarks" "$HOME/.config/nitrogen/nitrogen.cfg"
do
    [ -f "${i}.template" ] || continue
    sed --in-place "s|/home/%USERNAME%|$HOME|g" "${i}.template"
    if [ -f "$i" ]
    then
        if diff -BEbZ "$i" "${i}.template" >/dev/null
        then
            rm "${i}.template"
        else
            mv "$i" "${i}${bkp_sfx}"
            mv "${i}.template" "$i"
        fi
    else
        mv "${i}.template" "$i"
    fi
done

# Create link to shared bunsen wallpapers directory
ln -sTf /usr/share/images/bunsen/wallpapers "$HOME/Pictures/wallpapers/bunsen"

# Set marker so this doesn't run again
touch "$HOME/.config/bunsen/bl-setup"

exit 0

autostart
Edit /usr/share/bunsen/skel/.config/openbox/autostart adding a comment and call to bl-new-user-setup

## SETTINGS START

## RUN USER SETUP SCRIPT
## Runs once only during a user's first logon, safe to remove.
/usr/lib/bunsen/configs/bl-new-user-setup &

# What behaviour changes:
Both adduser and useradd default to creating bunsen style users (easily overridden).

# What this fixes:
No graphical login if the user's login group doesn't match their name. ( AD logins or USERGROUPS=no )
No graphical login for root after manually enabling the account.
No graphical login or user setup for:
Active Directory users (the point of the excercise).
Other cases where "$HOME" isn't exactly "/home/$USER"
Examples resulting in the above being:
If GROUPHOMES or LETTERHOMES are set to yes in /etc/adduser.conf
If the keys DHOME= (adduser) or HOME= (useradd) are reconfigured.
If the user specifies a different location (useradd or adduser) on the commandline.

# Why I like this one:
It greatly simplifies adding users for anyone new to linux as simply doing

sudo adduser newuser

gets you "newuser" configured bunsen-style, and in a reasonable set of groups which ought to hopefully forestall questions.
It's very convenient to add a new administrative account

sudo adduser -c /etc/adduser.bunsen.admin newuser

It's also more convenient than before to create a user with a "barebones" OpenBox setup by simply doing

sudo adduser -c /etc/adduser.default.debian newuser

Rather than remembering to login from a tty and create ~/.config/bunsen/bl-setup for that user after creating them, nor is there any file in their ~/ which if deleted would result in user setup running, nor any autostart entry to ever call it, just generic default OpenBox stuff.

Similarly useradd gets a bunsen-style user, though groups and suchlike options still require specifying, a "barebones" user can be created by

sudo useradd -m -k /etc/skel [other options] newuser

again with no special steps required at first login, and no need to create flags prior to graphical login.

Example config files are now present for adduser, so that someone wishing to use bunsen in e.g. a small school environment has the clues to easily deduce how to set up:
adduser.faculty
adduser.administration
adduser.students
and easily isolate classes of account, much as AD users get segregated into "/home/domain.tld/*", by enabling grouphomes and other minor tweaks.

For the root account, when using this method, giving root a bunsen-style environment involves copying the content of /usr/share/bunsen/skel to /root before root's first login.  You may wish to consider adding "Enabling and routinely using the root account" to the "Dangerous things" which need understanding in bl-welcome smile

@devs
For my own convenience during testing to ensure exact reproduceability, I created myself a little script, which makes all the above changes, backing up the original configuration first, and by being re-run, restores the previous configuration. With the exception that added user accounts remain.  I provide it below, for the convenience of any devs wishing to investigate and test things out themselves. I've tried just about every "corner case" with the exception of post install manually encrypted $HOME that I could think of smile but obviously proper testing would be required.  My little script may be over-commented, a function of the fact I generally script by writing comments first, then revising those as I go along.
# Script:

#!/bin/bash
# Script to update new user setup method on first login.


# Check if previously run, if not proceed, otherwise offer to reverse the process.
if [[ ! -d "/usr/share/bunsen/backup" ]]; then
	# Perform checks it's safe to continue,
	# i.e. We're not changing any settings already modified by a user.
	# This will be quick and dirty, not production standard.
	
	#adduser
	if  [[ $( grep SKEL= /etc/adduser.conf) != "SKEL=/etc/skel" ]]; then
		echo "/etc/adduser.conf has been reconfigured"
		echo "Expecting:"
		echo "SKEL=/etc/skel"
		echo "Got:"
		grep "SKEL=" /etc/adduser.conf
		echo "Cannot continue, quitting."
		exit 1
	fi
	
	#lightdm
	if [[ $(grep bl-user-setup /etc/lightdm/lightdm.conf.bunsen) != "session-setup-script=/usr/lib/bunsen/configs/bl-user-setup" ]]; then
		echo "/etc/lightdm/lightdm.conf has been reconfigured"
		echo "Expecting:"
		echo "session-setup-script=/usr/lib/bunsen/configs/bl-user-setup"
		echo "Got:"
		grep bl-user-setup /etc/lightdm/lightdm.conf.bunsen
		echo "Cannot continue, quitting."
		exit 1
	fi
	
	#openbox-autostart
	if [[ ! $(md5sum /usr/share/bunsen/skel/.config/openbox/autostart | grep "2f25c7cee0cd776046fe8c12aa44a393" ) ]]; then
		echo "/usr/share/bunsen/skel/.config/openbox/autostart has been reconfigured"
		echo "md5sum mismatch"
		echo "Cannot continue, quitting."
		exit 1
	fi
	
	#useradd
	if [[ $(grep SKEL= /etc/default/useradd) != "# SKEL=/etc/skel" ]]; then
		echo "= /etc/default/useradd has been reconfigured"
		echo "Expecting:"
		echo "# SKEL=/etc/skel"
		echo "Got:"
		grep SKEL= /etc/default/useradd
		echo "Cannot continue, quitting."
		exit 1
	fi
	#bl-user-setup
	if [[ ! $(md5sum /usr/lib/bunsen/configs/bl-user-setup | grep "d384b6570decfa4ba16679a7afe70ba8" ) ]]; then
		echo "/usr/lib/bunsen/configs/bl-user-setup is not the default version,"
		echo "however, it will be backed up as part of the process."
	fi
	echo "(Basic) Pre-checks passed!"
	read -p "Do you wish to continue?" -n 1 -r
	echo
	if [[ ! $REPLY =~ ^[Yy]$ ]]; then
		exit 1
	fi
	
	## First order of business, back up every file we're going to edit or replace.

	# Make backup dir
	sudo mkdir -p  /usr/share/bunsen/backup
	
	# Copy preserving attribs and ownership:
	cd /
	for file in "/etc/adduser.conf"	"/etc/default/useradd" "/etc/lightdm/lightdm.conf.bunsen" "/usr/lib/bunsen/configs/bl-user-setup" "/usr/share/bunsen/skel/.config/openbox/autostart"
	do
		sudo cp -a "$file" /usr/share/bunsen/backup
	done
	
	## Modification process starts.
	
	## Enable getting the stock debian behavior from adduser by using: 
	# "--conf /etc/adduser.stock.debian" or "-c /etc/adduser.stock.debian"
	sudo cp -a /etc/adduser.conf /etc/adduser.stock.debian
	
	## Configure adduser:
	# To use /usr/share/bunsen/skel instead of /etc/skel
	sudo sed -i "s|SKEL=/etc/skel|SKEL=/usr/share/bunsen/skel|g" /etc/adduser.conf
	# To set sensible groups for adding ordinary users
	sudo sed -i 's|#EXTRA_GROUPS="dialout cdrom floppy audio video plugdev users"|EXTRA_GROUPS="dip cdrom floppy audio video plugdev lp"|g' /etc/adduser.conf
	# Make putting added users in these groups the default behaviour
	sudo sed -i "s|#ADD_EXTRA_GROUPS=1|ADD_EXTRA_GROUPS=1|g" /etc/adduser.conf
	# Copy that where we want it
	sudo cp -a /etc/adduser.conf /etc/adduser.bunsen.user
	# Revise it for "admin" users so we can do "-c /etc/adduser.bunsen.admin"
	sudo sed -i 's|EXTRA_GROUPS="dip cdrom floppy audio video plugdev lp"|EXTRA_GROUPS="sudo dip cdrom floppy audio video plugdev netdev lp"|g' /etc/adduser.conf
	sudo mv /etc/adduser.conf /etc/adduser.bunsen.admin
	# Make the default behaviour creating ordinary bunsen users
	sudo ln -s /etc/adduser.bunsen.user /etc/adduser.conf
	
	## Configure LightDM to no longer call bl-user-setup
	sudo sed -i "s|session-setup-script=/usr/lib/bunsen/configs/bl-user-setup|#session-setup-script=|g" /etc/lightdm/lightdm.conf.bunsen
	
	## Add entry to openbox autostart in the bunsen skel
	sudo sed -i "s|## SETTINGS START|## SETTINGS START\n\n## RUN USER SETUP SCRIPT\n## Runs once only during a user's first logon, safe to remove.\n/usr/lib/bunsen/configs/bl-new-user-setup \&|g"  /usr/share/bunsen/skel/.config/openbox/autostart
	
	## Configure useradd:
	# Provide the original config file for inspection
	sudo cp -a /etc/default/useradd /etc/default/useradd.stock.debian
	# To use /usr/share/bunsen/skel instead of /etc/skel
	sudo sed -i "s|# SKEL=/etc/skel|SKEL=/usr/share/bunsen/skel|g" /etc/default/useradd
	# Put it where we want
	sudo mv /etc/default/useradd /etc/default/useradd.bunsen
	# Make userradd use it
	sudo ln -s /etc/default/useradd.bunsen /etc/default/useradd

	## Remove original bl-user-setup
	sudo rm /usr/lib/bunsen/configs/bl-user-setup

	## Write new version, this breaks with sudo streight to the target "permission denied"
	cat > ~/tmp/bl-new-user-setup << USERSETUP
#!/bin/bash
# Modified BunsenLabs User Set-up

# exit immediately if previously run
[ -f "\$HOME/.config/bunsen/bl-setup" ] && exit 0

# Check for running on a non-bunsen \$HOME (e.g. in a terminal, or by editing start-up files)
if [[ ! -d "\$HOME/.config/bunsen" ]]; then
	# Post Error
	echo "Error: Script cannot update a non-bunsen account. Exiting."
	exit 1
fi

bkp_sfx="~\$( date +%FT%T )~"

# Set correct path in ~/.gtk-bookmarks and ~/.config/nitrogen/nitrogen.cfg
# For clarity, these should probably be updated in /usr/share/bunsen/skel
# such that sed replaces %HOMEDIR% in this loop
for i in "\$HOME/.gtk-bookmarks" "\$HOME/.config/nitrogen/nitrogen.cfg"
do
    [ -f "\${i}.template" ] || continue
    sed --in-place "s|/home/%USERNAME%|\$HOME|g" "\${i}.template"
    if [ -f "\$i" ]
    then
        if diff -BEbZ "\$i" "\${i}.template" >/dev/null
        then
            rm "\${i}.template"
        else
            mv "\$i" "\${i}\${bkp_sfx}"
            mv "\${i}.template" "\$i"
        fi
    else
        mv "\${i}.template" "\$i"
    fi
done

# Create link to shared bunsen wallpapers directory
ln -sTf /usr/share/images/bunsen/wallpapers "\$HOME/Pictures/wallpapers/bunsen"

# Set marker so this doesn't run again
touch "\$HOME/.config/bunsen/bl-setup"

exit 0
USERSETUP
	
	# Check that wrote out correctly!
	if [[ ! $( md5sum ~/tmp/bl-new-user-setup | grep "ad3424bf47c9a3aa2a35d8a21376bcbe" ) ]]; then
		echo "Error: md5 mismatch, bl-new-user-setup written incorrectly!"
		echo "Expected md5 = ad3424bf47c9a3aa2a35d8a21376bcbe Got:"
		md5sum ~/tmp/bl-new-user-setup
		echo "Please re-run this script to restore changes made."
		echo " "
		exit 1
	fi

	# Put it where we want, since sudo wouldn't cat it there to begin with
	sudo mv -f ~/tmp/bl-new-user-setup /usr/lib/bunsen/configs/bl-new-user-setup
	
	# Make it belongs to root
	sudo chown root:root /usr/lib/bunsen/configs/bl-new-user-setup
	
	# Set executeable
	sudo chmod 755 /usr/lib/bunsen/configs/bl-new-user-setup
	
	## Modifications end
	
	## User information:
	clear
	echo "Modification of user setup complete"
	echo
	echo "IMPORTANT:"
	echo "The process for creating a minimal unconfigured user has changed."
	echo "The method is now:"
	echo
	echo "adduser:"
	echo "sudo adduser [other options] --conf /etc/adduser.stock.debian USER"
	echo "or"
	echo "sudo adduser [other options] -c /etc/adduser.stock.debian USER"
	echo 
	echo "Doing this will result in the previous (stock debian) behaviour."
	echo
	echo "useradd:"
	echo "sudo useradd -m -k /etc/skel [other options] USER"
	echo "or"
	echo "sudo useradd --create-home --skel /etc/skel [other options] USER "
	echo
	echo "A fully configured bunsen environment will be set unless the -k"
	echo "option specifies the /etc/skel directory."
	echo
	echo "No other actions are required for this purpose."
	echo
	exit 0
fi

# Only get here when backup dir not present.
# Running a second pass, backup directory detected.
clear
echo "This script has been run before on this computer, running it again"
echo "will revert changes made in the previous run, and return you to the"
echo "previous user setup configuration."
echo
echo "Note:"
echo "Reverting will result in any users added after the first run calling"
echo "a non-existant script from their openbox autostart."
echo
echo "Are you sure you want to restore your old configuration? "
read -p "Type: Restore to continue, anything else to quit." restore
if [ "$restore" != "Restore" ]; then
	exit 2
fi

# Remove extra files created by this script's previous run:
sudo rm -f /usr/lib/bunsen/configs/bl-new-user-setup
sudo rm -f /etc/adduser.stock.debian
sudo rm -f /etc/adduser.bunsen.user
sudo rm -f /etc/adduser.bunsen.admin
sudo rm -f /etc/default/useradd.stock.debian
sudo rm -f /etc.default/useradd.bunsen
# Probably not there but, in case of md5 mismatches
rm -f  ~/tmp/bl-new-user-setup

# Copy files back from backup
sudo cp -a --remove-destination /usr/share/bunsen/backup/adduser.conf /etc/adduser.conf
sudo cp -a --remove-destination /usr/share/bunsen/backup/useradd /etc/default/useradd
sudo cp -a --remove-destination /usr/share/bunsen/backup/lightdm.conf.bunsen /etc/lightdm/lightdm.conf.bunsen
sudo cp -a --remove-destination /usr/share/bunsen/backup/bl-user-setup /usr/lib/bunsen/configs/bl-user-setup
sudo cp -a --remove-destination /usr/share/bunsen/backup/autostart /usr/share/bunsen/skel/.config/openbox/autostart

# Delete the backup
sudo rm -rf /usr/share/bunsen/backup

exit 0

Should it be deemed desirable, removed parts ( rsync, chown? ) could be left in place and made conditional on the script being run in a terminal.
useradd could also be left untouched, if one is willing to respond to forum questions about "My new user didn't get a bunsen setup?" with "Remove them then use adduser, not useradd".


## Method 2 ##

Running as root pre login from LightDM as requested by @johnraff by a simple revision of the existing process.

# What this fixes:
The same broken logins as Method 1 with the (untested) but highly probable exception of manually encrypted $HOME

# Revised bl-user-setup

#!/bin/bash
# Modified BunsenLabs User Set-up

# HOME is exported by lightdm
[ -f "$HOME/.config/bunsen/bl-setup" ] && exit 0

# Because it's not there yet for first-time Active-Directory logins
[[ ! -d "$HOME" ]] || mkdir -p "$HOME"

bkp_sfx="~$( date +%FT%T )~"

rsync -rltb --suffix="$bkp_sfx" --safe-links /usr/share/bunsen/skel/ "$HOME"

# For clarity, these should probably be updated in /usr/share/bunsen/skel
# such that sed replaces %HOMEDIR% here
for i in "$HOME/.gtk-bookmarks" "$HOME/.config/nitrogen/nitrogen.cfg"
do
    [ -f "${i}.template" ] || continue
    sed --in-place "s|/home/%USERNAME%|$HOME|g" "${i}.template"
    if [ -f "$i" ]
    then
        if diff -BEbZ "$i" "${i}.template" >/dev/null
        then
            rm "${i}.template"
        else
            mv "$i" "${i}${bkp_sfx}"
            mv "${i}.template" "$i"
        fi
    else
        mv "${i}.template" "$i"
    fi
done

ln -sTf /usr/share/images/bunsen/wallpapers "$HOME/Pictures/wallpapers/bunsen"

mkdir -p "$HOME/.config/bunsen" # this should already exist
touch "$HOME/.config/bunsen/bl-setup"

# Took ages to figure out chown -R "$USER":"$USER" was broken,
# why it was, why that broke AD login, and how to fix it.
chown -R "$USER": "$HOME"

exit

# Why I'm nervous about this one:
Basically it's because users may set up encrypted ~/ manually post-install. Reading through the docs on doing that linked by @damo here I see that the decrypt on encrypted home directories when this method is used is called in /etc/pam.d/common-session, and consequently at the same time as pam_mkhomedir.so is called to create $HOME for Active Directory users, which gets created after this script runs in the latter case, hence having to make it in the script.

Thus logic suggests* that at the time bl-user-setup is called by LightDM $HOME is still encrypted at rest in the same way as $HOME hasn't yet been created for a fresh AD login.  As such if the encryption is any good it will be impossible to read ~/.config/bunsen/bl-setup or indeed any file below ~/ for the user logging in.

I have no idea what the consequences of a script running with root privilges consequently trying to rsync the contents of /usr/share/bunsen/skel and subsequently modify files, create a directory and file inside an encrypted directory at rest would be. Harmless failure? Data Corruption? Complete data loss for that user?  I have little interest in setting it up to find out, preferring the less error prone options of choosing encrypted LVM during system setup, and explicitly encrypting individual archives or documents to transmit, if I must for security encrypt.

There is no such risk using Method 1 as the user is already logged in, ~/ decrypted, and the flag to check is thus readable at the time Method 1's script is called, moreover it no longer copies the content of /usr/share/bunsen/skel merely runs sed over 2 files and creates a symlink and flag, even if inadvertenly re-run this is harmless sed does nothing owing to those files not containing what it's trying to replace, the symlink already exists, even if gets replaced it's with a new identical link, and creating a 0Byte file below ~/.config/bunsen/ in the context of the logged on user should cause no issues.

Judging by this thread we have at least one user who has encrypted this way.

This is, of course, irrelevent in the case of other encryption schemes such as the more typical whole disk LUKS or LUKS over LVM types, as the decrypt takes place at boot, before LightDM runs.

# Other things I don't like about it:
Relies on LightDM, many users like/prefer SLiM, GDM, or dispensing with a DM and logging in at a TTY.
Runs as root for file operations that don't need root.
If a user for any reason has a file with ownership other than "$USER":$(id -g "$USER") which 'chown -R "$USER": "$HOME"' sets [the : is vital], below ~/ and ~/.config/bunse/bl-setup gets deleted, the ownership is silently changed at next login, along with a slew of files being created.

## What remains broken (both methods):

Login now works but user configuration fails, openbox autostarts don't run, and various xsession errors are logged, in any case where "$HOME" contains white-space. A corner case which should only arise when AD users have names with a space which Windows and Active Directory both permit, though most Administrators don't. I created one explicitly just to test.

The same issues (I've confirmed this) arise if a user is created where $HOME is defined as "/home/some dir/user" which adduser and useradd both permit while forbidding white-space in the actual username by default.  Linux admins really ought to know better! I'm a Windows admin tongue

That's a whole other project, I seem to remember that LXDE survives this silliness, which is doubtless down to where double quotes appear or are omitted in config files and startup scripts read/called prior to openbox autostart.  Debian also recommend against such white-space, citing possible unforseen consequences running who-knows-what software not tested against such configurations, I can't remember where OTOH but I do remember reading it.  As such, I'm not going to post a bug and expect devs to investigate (unless they wish to), though if I turn up causes and cures myself I may then decide to do so, with the offending files and needed changes all nicely stated.

* Kettering's Law may apply.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

Board footer

Powered by FluxBB