Adding maintainer of filesystem.

the solution here is to simply not ship any skel files and not clutter new users's homes. What we do need to keep is the bin directory though. That is important for 3rd party installers.

in aaa_base we only have
/etc/skel/.emacs
/etc/skel/.inputrc

werner can we move these last two to the respective packages ?
readline for the .inputrc and some common package for the .emacs
base stub ?

or rather drop them without replacement. They are just cluttering new users homes.

I don't buy this argument. I meanwhile have about 400 dotfiles/dotdirs in my SUSE"s  $HOME (exists since 1999) and 8 are coming
from /etc/skel. So I would say using a $HOME for a longer time dotfiles coming from /etc/skel would be not more than 5%-10%. The remaining dotfiles/dotdirs are coming from program creating them on demand.

I think best would be to work with /usr/etc/skel and /etc/skel as it's proposed in 

  https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Variant_3

For this we would need a patch for useradd at least (shadow package). I don't know whether there are other programs/scripts
on our distribution adding users and the initial $HOME for them. Is YaST using useradd? I have no idea ...

(In reply to Ruediger Oertel from comment #3)
> in aaa_base we only have
> /etc/skel/.emacs
> /etc/skel/.inputrc
> 
> werner can we move these last two to the respective packages ?
> readline for the .inputrc and some common package for the .emacs
> base stub ?

The .emacs belongs to GNU Emacs as well as to X Emacs ... the .inputrc to every progrqm using libreadline (not only bash does this).  Not sure if X Emacs should require GNU Emacs or e.g. gnuplot require the bash:

 rpm -q --whatrequires 'libreadline.so.7()(64bit)' | wc -l
 42

(In reply to Ludwig Nussel from comment #4)
> or rather drop them without replacement. They are just cluttering new users
> homes.

Why do we drop all possible user based configurations?  This is how users can do this and without such templates the skeleton feature of useradd becomes rather useless.

(In reply to Stefan Dirsch from comment #6)
> I think best would be to work with /usr/etc/skel and /etc/skel as it's
> proposed in 
> 
>   https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Variant_3
> 
> For this we would need a patch for useradd at least (shadow package). I
> don't know whether there are other programs/scripts
> on our distribution adding users and the initial $HOME for them. Is YaST
> using useradd? I have no idea ...

YaST does make use of the skeleton ... if it happesn by using useradd (what is very likly) I have not tested, but a test user foobar shows after leaving with OK the user/group menue shows a valid user home with all templates from the skeleton package.

I don't have a good idea for emacs.

for the readline config I thought about having a "readline-config" subpackage
of the readline package to be required by the libreadline binary packages.
wrong approach ? on the other hand this is extremely esoteric since I can
not envision any system without a libreadline installed, such the file would
be more often forced into the system than with the current location in
aaa_base-extras ...

summary: for the aaa_base side I'd just move the two files from etc/skel
to usr/etc/skel if useradd can deal with that.

Werner, didn't you want to drop xemacs anyway? ;-) So just move /etc/skel/.emacs to GNU emacs package ...

useradd would need a patch to handle both - /etc/skel and /usr/etc/skel - in this order. It would be easy to switch skel dir for useradd to /usr/etc/skel, but this would be a loss in functionality as the sysadmin no longer can adjust the skeleton settings ...

(In reply to Stefan Dirsch from comment #9)
> Werner, didn't you want to drop xemacs anyway? ;-) So just move
> /etc/skel/.emacs to GNU emacs package ...

That would be a possiblity which will bounce any X Emacs user on his/her nose ;)

> 
> useradd would need a patch to handle both - /etc/skel and /usr/etc/skel - in
> this order. It would be easy to switch skel dir for useradd to
> /usr/etc/skel, but this would be a loss in functionality as the sysadmin no
> longer can adjust the skeleton settings ...

Isn't that a decision of the maintainers of package shadow?  Indeed it is a feature to give the system admin the possiblity to decide which templates from /usr/etc/skel will be part of /etc/skel and which not. Nevertheless a README which has to be ignored by useradd would be an option.

Created attachment 841688 [details]
useradd.local.patch

This patch for useradd.local implements copying of skel files from /usr/etc/skel, which don't exist in /etc/skel.

That would be the only needed change for shadow package. Feel free to review the patch.

adding mvetter as shadow package maintainer

(In reply to Dr. Werner Fink from comment #7)
> (In reply to Ludwig Nussel from comment #4)
> > or rather drop them without replacement. They are just cluttering new users
> > homes.
> 
> Why do we drop all possible user based configurations?  This is how users
> can do this and without such templates the skeleton feature of useradd
> becomes rather useless.

Maybe I was misleading. Of course useradd needs to support /usr/etc/skel and /etc/skel. The point for aaa_base is that the files we ship there so far have very little value. Ie the inputrc is just comments and the code in the emacs file should be in the global emacs config if it's useful. That way even existing users would benefit from that code and we can even fix/extend it in the future. There's no need to copy templates/boiler plates into user homes.

I can not answer that question, the files are in aaa_base only due to the lack
of another "common" package to hold them.

werner ?

Let's reassing to shadow package maintainer.

Werner? Michael, could you have a look at my patch? (comment #11)

(In reply to Stefan Dirsch from comment #11)
> Created attachment 841688 [details]
> useradd.local.patch
> 
> This patch for useradd.local implements copying of skel files from
> /usr/etc/skel, which don't exist in /etc/skel.

With

  shopt -s dotglob

it would be possible to use

  shopt -s dotglob
  for file in ${USRSKELDIR}/*; do
      file=${file##*/}
      # Only copy if not exist yet, i.e. does *not* exist in /etc/skel, which is still
      # being preferred ...
      test -e $HOMEDIR/$file && continue
      cp -a $USRSKELDIR/$file $HOMEDIR
      chown -R $USER.$GID $HOMEDIR/$file
  done

That's magic to me, but if it works and has been tested. Wonderful! :-)

Werner, could you submit a shadow package with your useradd patch, please? You could even accept it then yourself, since you're maintainer of Base:System.

(In reply to Stefan Dirsch from comment #20)
> Werner, could you submit a shadow package with your useradd patch, please?
> You could even accept it then yourself, since you're maintainer of
> Base:System.

Hmmm ... it looks like there is a change

--- /usr/sbin/useradd.local     2020-06-08 22:12:52.000000000 +0200
+++ tmp/useradd.local   2020-10-09 12:28:23.143661000 +0200
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh

... which leads to the fact that ``shopt -s dotglob`` might not work with /bin/sh not linked to bash


Fri May 22 11:21:15 UTC 2020 - Fabian Vogt <fvogt@suse.com>

- Use pure #!/bin/sh in:
  * useradd.local
  * userdel-post.local
  * userdel-pre.local

So revert this for useradd.local. ;-)

Fabian? What is the rational for this switch from bash to sh?

(In reply to Stefan Dirsch from comment #20)
> Werner, could you submit a shadow package with your useradd patch, please?
> You could even accept it then yourself, since you're maintainer of
> Base:System.

Hi! Sorry for the long delay. I was on vacation. Being back now I can accept the SR once it's ready.

(In reply to Dr. Werner Fink from comment #23)
> Fabian? What is the rational for this switch from bash to sh?

That shadow can be used without bash, for instance with busybox sh or dash. That was a requirement for carwos and can be useful outside of that as well, especially because it didn't need any changes beyond that.

(In reply to Fabian Vogt from comment #25)
> (In reply to Dr. Werner Fink from comment #23)
> > Fabian? What is the rational for this switch from bash to sh?
> 
> That shadow can be used without bash, for instance with busybox sh or dash.
> That was a requirement for carwos and can be useful outside of that as well,
> especially because it didn't need any changes beyond that.

Hmm ... then there is no way that the ``sh'' is able to list hidden files anymore.

 > busybox-static sh
 $ for f in /etc/skel/*; do echo $f ; done
 /etc/skel/bin
 $ 

...

 > dash
 $ for f in /etc/skel/*; do echo $f ; done
 /etc/skel/bin
 $ 

now this requires the usage e.g. of `-A` option of the `ls` command/builtin

 > busybox-static sh
 $ ls -A /etc/skel    
 .bash_history  .claws-mail  .dvipsrc  .fonts      .i18n     .local   .profile   .xim.template      bin
 .bashrc        .config      .emacs    .gnu-emacs  .inputrc  .muttrc  .urlview  .xinitrc.template

 > dash
 $ ls -A /etc/skel
 .bash_history  .claws-mail  .dvipsrc  .fonts      .i18n     .local   .profile   .xim.template     bin
 .bashrc        .config      .emacs    .gnu-emacs  .inputrc  .muttrc  .urlview  .xinitrc.template

Also there is code above in useradd.local which looks like this


# If SELinux is enabled, we have to run restorecon to assign
# appropriate fcontexts to the respective $HOME and files under it
if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled ; then
  test -x /sbin/restorecon || exit 2

  if [ $# -lt 4 ]; then
    home_dir=/home/$1
  else
    home_dir=$4
  fi

  if [ -d $home_dir ]; then
      /sbin/restorecon -R $home_dir
  fi
fi

... therefore the HOME dsetting in Stefan approach might be wrong
(e.g. if useradd has seen four arguments with an other HOME dir)

Created attachment 842468 [details]
An other approach

any comments and/or suggestions?

This is an autogenerated message for OBS integration:
This bug (1173321) was mentioned in
https://build.opensuse.org/request/show/840431 Factory / shadow

(In reply to Dr. Werner Fink from comment #29)
> Created attachment 842468 [details]
> An other approach
> 
> any comments and/or suggestions?

The first 

  HOMEDIR=$HOME/$USER

is not needed, but I think it doesn't hurt either. Thanks for submitting the patch!

(In reply to Stefan Dirsch from comment #31)
> (In reply to Dr. Werner Fink from comment #29)
> > Created attachment 842468 [details]
> > An other approach
> > 
> > any comments and/or suggestions?
> 
> The first 
> 
>   HOMEDIR=$HOME/$USER
> 
> is not needed, but I think it doesn't hurt either. Thanks for submitting the
> patch!

Indeed doppelt gemoppelt ... done twice

(In reply to OBSbugzilla Bot from comment #30)
> This is an autogenerated message for OBS integration:
> This bug (1173321) was mentioned in
> https://build.opensuse.org/request/show/840431 Factory / shadow

Yeah. It has been accepted. Bug can be closed, i.e. packages now can move their skel files to /usr/etc/skel. But this doesn't need to be tracked here.

This is an autogenerated message for OBS integration:
This bug (1173321) was mentioned in
https://build.opensuse.org/request/show/842793 Factory / filesystem

This is an autogenerated message for OBS integration:
This bug (1173321) was mentioned in
https://build.opensuse.org/request/show/847777 Factory / shadow

This has now been upstreamed: https://github.com/shadow-maint/shadow/pull/591