[Helium-dev] TTY boot option & startx fails to configure desktop

Head_on_a_Stick · 2018-03-11 14:13:14

johnraff wrote:

no need for the .sh, as it's sourced, not executed directly

Yes, of course, thanks — I can't believe I added that

Doesn't /etc/profile only source scripts in /etc/profile.d/ that end with .sh?

Last edited by Head_on_a_Stick (2018-03-11 15:12:49)

johnraff · 2018-03-12 06:13:28

Head_on_a_Stick wrote:

johnraff wrote:
no need for the .sh, as it's sourced, not executed directly
Yes, of course, thanks — I can't believe I added that

You didn't. I put it in, then forgot. :8
(It shouldn't need the shebang #!/bin/sh though.)

Doesn't /etc/profile only source scripts in /etc/profile.d/ that end with .sh?

Right! I don't know why the .sh restriction was added, but in base-files between Lenny and Squeeze that profile.d code got put in, and this section of the FAQ, denigrating profile.d, got taken out:

base-files_5lenny FAQ wrote:

* Questions about "profile.d":
Q. Why does Debian not have a "profile.d" directory, like other distributions?
A. Because no Debian package needs it. Debian policy says: "A program
must not depend on environment variables to get reasonable defaults".
This policy has been very successful so far. If the default install
had a profile.d, people might think it's ok to use it for a Debian
package, when in fact policy does not support such thing.
Q. Ok, but I still think it would still be a nice thing to have, would
not make sense to have a profile.d by default, even if no Debian
package uses it?
A. No. As explained before, there is the risk of assuming that it's
"officially supported". If you need a profile.d directory, you may
still create one in your machine and modify your /etc/profile
accordingly to enable it. Since this is a configuration file,
its contents will be preserved in upgrades.
Q. Ok, but if I do that I will have to merge my changes every time
the /etc/profile provided by base-files changes.
A. That should not be a big problem. The default /etc/profile provided
by base-files is quite minimal on purpose, and it is not expected to
change drastically from one Debian release to the next one.

So it now seems to be grudgingly acceptable to use profile.d, at least for our simple conditional message. We'll be careful not to set any envvars Aunty Debian!

Last edited by johnraff (2018-03-12 08:19:10)

johnraff · 2018-03-12 09:00:07

I've provisionally added this to /etc/profile.d in bunsen-configs:

# /etc/profile.d/bunsen.sh
# BunsenLabs message

if [ ! -f "${HOME}/.config/bunsen/bl-setup" ] && [ "$TERM" = "linux" ]; then
    echo "
There seem to be no configuration files for the BunsenLabs desktop.
Please run 'bl-user-setup' if you'd like to generate them.
"
fi

I found the extra spacing a bit too assertive, so toned the formatting down to resemble the other login messages.
@HoaS does that look OK on your machine?

Head_on_a_Stick · 2018-03-12 20:02:11

^ Looks good but I would prefer it double-spaced (ie, with a blank line between the sentences).

johnraff · 2018-03-13 06:06:43

johnraff wrote:

I found the extra spacing a bit too assertive

Er, so it seems we don't quite agree on that point.

I just imagined some advanced user getting increasingly annoyed being reminded of some install they had no intention of doing, so just tried to blend our message in with the others. "You have mail" doesn't exactly stand out either. At least ours has preceding and trailing blank lines.

I think there's a case for leaving the whole thing out, to be honest. CLI users shouldn't need too much hand-holding.

Last edited by johnraff (2018-03-13 06:07:54)

Head_on_a_Stick · 2018-03-13 07:53:49

johnraff wrote:

CLI users shouldn't need too much hand-holding.

Yes but using a random script run by the display manager to configure a graphical desktop is entirely non-obvious — I've been helping out with #! since 2014 and I only found out that was how it was being done a few months ago.

Most people would suppose that the configuration files had simply been added to /etc/skel (as ArchLabs does it) because that's the most obvious method and it requires no further levels of abstraction and is not reliant upon a display manager; tbh I'm still not completely clear why we don't do that but that's off-topic.

If you don't want to add this, that's fine.

johnraff · 2018-03-13 08:24:50

No let's keep it.

The reason we don't use skel has been discussed at length - it wasn't an autocratic decision by anyone. Please use the forum search function.

johnraff · 2018-03-14 06:06:31

Head_on_a_Stick wrote:

I've been helping out with #! since 2014 and I only found out that was how it was being done a few months ago.

johnraff wrote:

Please use the forum search function.

Unfortunately I originally brought this up in a Development thread not here but on CrunchBang, in May 2015 so @HoaS you should have been aware of it, though you didn't make any comment at the time.
The Internet Archive haven't got this particular page, and the #! software have erased most of it till you log in and use "quote" or "edit", but it's here: https://crunchbang.org/forums/viewtopic.php?id=39678

johnraff (in 2015) wrote:

(techy topic)
The way CrunchBang, and BunsenLabs at the moment, populates the user home directory with config files is by a script (/usr/lib/bunsen/bunsen-configs/bl-user-setup in our case), triggered at login time but only run once, which copies in the contents of /etc/skel.
/etc/skel is used by Debian to put a new .profile, .bashrc and .bash_logout into a newly created user's $HOME, so we're just joining in - except that the script pre-empts that process. However, it's not really recommended to put a lot of stuff in /etc/skel, and we're filling it with many, many files. Moreover, any file a package installs under /etc gets marked as a conffile by Debian which complicates upgrades. (I just hit an issue when trying to move a file from one package to another.)
So, is there any reason why we can't put all those config files in e.g. /usr/share/bunsen/bunsen-configs/skel? It would be just as easy for bl-user-setup to copy them from there as from /etc/skel I guess.
Any snags I haven't though of?

So the disadvantages of putting a whole slew of config files in /etc/skel:
1) Debian Policy doesn't approve.
2) dpkg will regard them as conffiles which sometimes causes subtle complications.
3) Every user on the system will get their $HOME populated with the default set of BL config files, whether they want them or not.
4) Some files (eg tint2conf) need full filepaths, which have to be changed for each user.
I think 3) is the most serious of these.

Now it's true that only X users who log in via LightDM (or Slim on #!) will trigger the setup script. People who use another DM or login on CLI and then run `startx` will miss it. That might be regarded as an advantage in the sense that only people who are running the default BL setup will get the default BL config automatically, but as the OP points out, such people might not know how to get the config, if they want it.

So our current solution of a warning message might be enough.

Another possibility, though, would be to put a file in /etc/X11/Xsession.d as I suggested, then abandoned, above. This would cause the config files to be imported for anyone running an X session, regardless of how they started it. (There might be exceptions for Display Managers which don't use the Debian xsession scripts.)

If that was seen as an advantage, we could think about applying it, though it would need testing for corner-cases - there might be subtle differences in the environment, or when doing remote logins for example. As a proof of concept I put this file in /etc/X11/Xsession.d/22bunsen-user-setup (it needs to be early in the sequence because later scripts look for user config files.)

# run BunsenLabs user setup script
# This file is sourced by Xsession(5), not executed.

if [ -x /usr/lib/bunsen/configs/bl-user-setup ]
then 
	echo 'Running bl-user-setup to import configuration files.' > "$HOME/.xsession-errors"
	/usr/lib/bunsen/configs/bl-user-setup
fi

Creating a new user 'test', logging in from tty2 and running startx, the config setup seemed to go OK.

Last edited by johnraff (2018-03-17 08:16:22)

Head_on_a_Stick · 2018-03-14 07:38:59

^ Thank you for the extended explanation, it is very helpful.

johnraff wrote:

May 2015 so @HoaS you should have been aware of it, though you didn't make any comment at the time.

At that time I would have only been interested in the problem threads, I didn't pay much attention to the other forum areas, sorry.

johnraff wrote:

put a file in /etc/X11/Xsession.d

I very much prefer this idea over a dependence on LightDM.

EDIT: as I have already mentioned elesewhere, dropping LightDM completely gives a significant security advantage so it would be nice to allow our users that choice with the minimum of hackage.

Last edited by Head_on_a_Stick (2018-03-14 07:40:43)

johnraff · 2018-03-14 09:47:45

We always prefer modularity and tweakability - philosphies inherited from CrunchBang - so let's have a serious look at this DM-agnostic setup script. I'll start a new thread on that specifically and we'll see if we get any potential problems raised by other users. If not, it can go in bunsen-configs, replacing the LightDM config, and make it into Helium.

martix · 2018-03-14 11:12:10

Head_on_a_Stick wrote:

...is entirely non-obvious...

That's about sums up a big chunk of my linux experience so far. But it's getting better.

Head_on_a_Stick wrote:

dropping LightDM completely gives a significant security advantage

What would be the best way for users to log-in without LightDM? Boot in tty and log-in from there?

My understanding was that a simple display manager starts X and user sessions (and shows login screen when configured that way), nothing complicated.

Head_on_a_Stick · 2018-03-14 21:35:22

martix wrote:

Head_on_a_Stick wrote:
dropping LightDM completely gives a significant security advantage
What would be the best way for users to log-in without LightDM? Boot in tty and log-in from there?

Yes, just running `startx` from a console log in will deliver the exact same desktop as if the user had logged in from LightDM[1] but without the extra running processes in the background (and any extra bugs they may be harbouring).

My understanding was that a simple display manager starts X and user sessions (and shows login screen when configured that way), nothing complicated.

Yes, that's why we don't need one

Even I will admit that releasing BunsenLabs without a display manager is not a realistic possibility but the advantage of running X as the normal user rather than as root is so great that I think we should try to make it as easy as possible.

[1] With the proviso that LightDM is needed to populate $HOME from /usr/share/bunsen/skel and configure the desktop on the first log in.

Last edited by Head_on_a_Stick (2018-03-14 21:36:40)

johnraff · 2018-03-15 03:16:05

Display Manager:

1) User login with password.

2) Allow choice of xsession based on .desktop files in /usr/share/xsessions/

3) Allow choice of locale, from what is installed on system (ie switch language).

4) Display users and choose one to login.

5) Bypass choice of default user, input password only.

6) Allow auto-login.

7) Look pretty.

Most of these can be done from the command line, but with more complication, especially 3).

Head_on_a_Stick · 2018-03-15 07:43:25

For those curious about the alternatives:

johnraff wrote:

1) User login with password.

TTY does that too.

2) Allow choice of xsession based on .desktop files in /usr/share/xsessions/

Changing desktops isn't something people do very often but galternatives would seem to accomplish that (for the next login session).

3) Allow choice of locale, from what is installed on system (ie switch language).

As above, not usually something that is usually changed on-the-fly, `setxkbmap` for the X session should fix things at the user level.

4) Display users and choose one to login.

That is not a good thing, IMO.

5) Bypass choice of default user, input password only.

That's even worse (again, IMO).

6) Allow auto-login.

https://wiki.archlinux.org/index.php/Sy … ay_manager

7) Look pretty.

Efficiency is more attractive to me.

johnraff · 2018-03-15 08:22:45

I wrote:

Most of these can be done from the command line

I wasn't challenging your assertion on that, merely adding that it's more complicated. Also, choosing some of these things on-the-fly is attractive to some users. Also, changing a locale is more than just rearranging the keyboard. (I have to deal with English and Japanese locales.)

HoaS wrote:

Efficiency is more attractive to me.

I'm well aware of your preferences. I was just pointing out to the general audience that there are, as usual, two sides to this. A blanket statement like "We don't need a DM" is too restrictive.

johnraff · 2018-03-15 08:23:51

Head_on_a_Stick wrote:

For those curious about the alternatives:
johnraff wrote:
1) User login with password.
TTY does that too.

Did you seriously think I - and most people - didn't know that?

martx wrote:

My understanding was that a simple display manager starts X and user sessions (and shows login screen when configured that way), nothing complicated.

In fact my post was addressed not to @HoaS but to @martx who asked what a DM does.

Last edited by johnraff (2018-03-15 08:27:45)

Head_on_a_Stick · 2018-03-15 08:34:16

johnraff wrote:

Did you seriously think I - and most people - didn't know that?

Then why mention it as a "feature" of the display manager?

My post was intended for the curious

johnraff · 2018-03-16 01:50:21

^I think you might have misunderstood the intention of my post. There was no mention of "features". I simply listed up what I thought Display Managers did, starting from the most obvious, in reply to martix's query, and because I thought he and you had left a couple of things out. I then said that most of that could be done from the command line too, but that a graphical DM made choosing a locale (nothing to do with keyboard layout btw) and session manager easier. I think we're basically agreed on all that.

Head_on_a_Stick · 2018-03-16 07:49:22

johnraff wrote:

I think we're basically agreed on all that.

Yes, definitely.

To be absolutely clear: I would never propose that BL drop the display manager.

johnraff · 2018-03-17 08:19:30

I think this comes under the heading of [ENHANCEMENT] rather than bug really, but anyway I've proposed changing to DM-agnostic config file imports here: https://forums.bunsenlabs.org/viewtopic.php?id=4672

#21 2018-03-11 14:13:14

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#22 2018-03-12 06:13:28

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#23 2018-03-12 09:00:07

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#24 2018-03-12 20:02:11

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#25 2018-03-13 06:06:43

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#26 2018-03-13 07:53:49

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#27 2018-03-13 08:24:50

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#28 2018-03-14 06:06:31

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#29 2018-03-14 07:38:59

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#30 2018-03-14 09:47:45

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#31 2018-03-14 11:12:10

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#32 2018-03-14 21:35:22

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#33 2018-03-15 03:16:05

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#34 2018-03-15 07:43:25

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#35 2018-03-15 08:22:45

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#36 2018-03-15 08:23:51

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#37 2018-03-15 08:34:16

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#38 2018-03-16 01:50:21

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#39 2018-03-16 07:49:22

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

#40 2018-03-17 08:19:30

Re: [Helium-dev] TTY boot option & startx fails to configure desktop

Board footer