LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 11-15-2013, 04:38 AM   #61
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 257

Original Poster
Rep: Reputation: 87

reaperx7, darth vader,

what if I make the build script in such a way, that you can enable/disable pam in that way.

Code:
# Set to YES to enable pam support
SBO_PAM=${SBO_PAM:-YES}

unset SBO_PAMOPTS
[ "${SBO_PAM}" = "YES" ] || SBO_PAMOPTS='--disable-pam'
 
Old 11-15-2013, 07:41 AM   #62
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,223

Rep: Reputation: Disabled
Quote:
Originally Posted by bartgymnast View Post
reaperx7, darth vader,

what if I make the build script in such a way, that you can enable/disable pam in that way.

Code:
# Set to YES to enable pam support
SBO_PAM=${SBO_PAM:-YES}

unset SBO_PAMOPTS
[ "${SBO_PAM}" = "YES" ] || SBO_PAMOPTS='--disable-pam'
That would make it a lot easier for people who consider trying out your work.

And in order to address unspawn's concerns: I sincerely dislike the whole concept of SystemD, and the way it is promoted. However, I do not regard your own work in any negative way - I encourage everybody to make more of his or her Slackware computer. If you end up with a working Slackware computer running SystemD, then that is a proper achievement which deserves respect, not scalding.

Eric
 
12 members found this post helpful.
Old 11-15-2013, 08:09 AM   #63
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0, CRUX 3.1
Posts: 3,010
Blog Entries: 15

Rep: Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756
1. Keeping rc.local usable is a key to keeping software daemons useful if they don't have, won't, or can't receive support through systemd. This is UNIX friendliness even while systemd isn't too POSIX compliant.

2. PAM disabled by default is a huge plus. PAM is just a bad concept from any way you look at it. I've had PAM lock out an entire system forcing a complete rebuild on LFS, and even after a week of backtracking through the system to see what went wrong, no solution except a reluctant rebuild solved it. Giving modulariry to ConsoleKit proves systemd can be minimized in impact. If even more can be modularized out that isn't necessary it'll reduce the overhead on lower end systems.

3. Documenting within the systemd daemon startup scripts will be a must have to ease transitioning. Having lots of predrafted handwritten scripts in a package all it's own will help rather than using the default scripts from the packages themselves.

You could always take the samples in the sysvinit and bsdinit scripts used by Slackware and translate them to systemd scripts with the commands altered only unless the systemd scripts do not allow for commented out embedded documentation in scripts.
 
Old 11-15-2013, 09:13 AM   #64
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 146Reputation: 146
Quote:
Originally Posted by bartgymnast View Post
THIS IS NOT A PLACE FOR FLAME WARS.
Of course not, and I think systemd does have its usefulness. While rpm manages dependencies of files, systemd can manage dependencies of processes. However, it takes time before people can see its benefit.

A similar thing is communism. When people see it's good they will have it. Don't tell people "you need it". It's already proved unsuccessful.
 
Old 11-15-2013, 09:21 AM   #65
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 257

Original Poster
Rep: Reputation: 87
UPDATE

- I am updating systemd slackbuild to have pam as option. [ standard disabled ]
- I am also updating systemd slackbuild to have default init as systemd as an option. [ standard disabled ]
- I am setting up a wiki instead of the current standard page, to extend the documentation.


ReaperX7:
rc.local is standard usable within systemd, and I made the needed effort to make sure that this works on Slackware.
you can actually create unit files to start from systemd for every daemon you want.
This is my inet1.service file (also included in the slackbuild)

Code:
#
# This inet1.service file is to start the old rc.inet1 netywork
# Also an example if little text can be written without breaking the script.
#

[Unit]
Description=Network Connectivity
Before=network.target
After=syslog.target
Wants=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rc.d/rc.inet1 start
ExecStop=/etc/rc.d/rc.inet1 stop
Creating systemd unit files from all scripts in /etc/rc.d/rc.xxx is an option.
And I could offer this as a seperate resource, so that people can copy them and enable if needed.

More Documentation is being setup with a wiki instead of the now standard page I have on the website.
 
3 members found this post helpful.
Old 11-15-2013, 10:24 AM   #66
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 257

Original Poster
Rep: Reputation: 87
UPDATE

Slackbuilds of Shadow and Systemd have been updated.
PAM is standard disabled. (also default init)
Read the slackbuild on how to boot into systemd if you leave the default init as /sbin/init. (lilo config addition required)

building shadow, systemd, dbus is sufficient to have systemd working.
I will update the openssh script for pam option aswell.

you can always start sshd with /etc/rc.d/rc.sshd start
 
Old 11-15-2013, 11:27 AM   #67
tuxbg
Member
 
Registered: Sep 2012
Location: Bulgaria,Varna
Distribution: Slackware64
Posts: 248

Rep: Reputation: Disabled
Do we need cracklib ?
 
Old 11-15-2013, 11:40 AM   #68
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 257

Original Poster
Rep: Reputation: 87
not if you build without pam.

openssh updated now aswell.
 
1 members found this post helpful.
Old 11-15-2013, 01:54 PM   #69
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 257

Original Poster
Rep: Reputation: 87
I have created a wiki now instead of the standard simple page

Systemd for Slackware wiki

You can find here information on howto install systemd with or without pam.
 
7 members found this post helpful.
Old 11-15-2013, 03:06 PM   #70
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 231

Rep: Reputation: 98
bartygymnast,

I was wondering if you could elaborate on your first bullet point on your Wiki page:
Quote:
  • udev is a complete part of systemd since v208, And can not be extracted seperatly anymore.
Doesn't Linux From Scratch describe performing just such an extraction?
 
1 members found this post helpful.
Old 11-15-2013, 03:52 PM   #71
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 257

Original Poster
Rep: Reputation: 87
It was possible before v208 to compile systemd, and extract the udev parts after compiling.

now you need to create your own Makefile, and use some parts of src/udev from systemd.
so they are not extracting imo, they are using parts of the source code.

thats why the line that it can not be extracted seperatly.

I have changed the description on thew wiki accordingly

Last edited by bartgymnast; 11-15-2013 at 04:01 PM.
 
Old 11-15-2013, 04:12 PM   #72
jprzybylski
Member
 
Registered: Apr 2011
Location: Canada
Distribution: Slackware
Posts: 97

Rep: Reputation: 23
Quote:
Originally Posted by bartgymnast View Post
It was possible before v208 to compile systemd, and extract the udev parts after compiling.

now you need to create your own Makefile, and use some parts of src/udev from systemd.

so they are not extracting imo, they are using parts of the source code.

thats why the line that it can not be extracted seperatly.
In that case, I think it is less that udev cannot be extracted (because some distros do, even if it's with custom Makefiles), and more that extracting udev from systemd is unsupported.
 
1 members found this post helpful.
Old 11-15-2013, 04:13 PM   #73
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0, CRUX 3.1
Posts: 3,010
Blog Entries: 15

Rep: Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756
systemd-208 can still have udev extracted. LFS still uses this method but yes it is a custom makefile to modularize it and udev-extras out from the main tree.

I haven't seen any efforts yet to make udev un-extractable, though eudev and other udev-like projects are still in heavy development as a replacement, eudev was work last I saw, as well as mdev. The only project that I have no idea about is Hotplug2.

Cracklib can be included without PAM. Though if you build shadow with SHA-512 support, it might not be required at all.

This is an excerpt from my LFS's shadow build-install-setup script on how to build shadow without PAM:

Code:
sed -i 's/groups$(EXEEXT) //' src/Makefile.in
find man -name Makefile.in -exec sed -i 's/groups\.1 / /' {} \;
sed -i -e 's@#ENCRYPT_METHOD DES@ENCRYPT_METHOD SHA512@' \
       -e 's@/var/spool/mail@/var/mail@' etc/login.defs
#sed -i 's@DICTPATH.*@DICTPATH\t/lib/cracklib/pw_dict@' \
#    etc/login.defs
./configure --sysconfdir=/etc
#./configure --sysconfdir=/etc --with-libcrack
make
make install
mv -v /usr/bin/passwd /bin
pwconv
grpconv
sed -i 's/yes/no/' /etc/default/useradd
passwd root
Alternatively you can build with Cracklib support, without PAM still, just switch out the comment lines for ./configure and uncomment the sed argument.

Hmmm... interesting thought I'm having, but how much more could be modularized out of systemd back to other daemons and handlers without removing the main init portion and daemon handlers? Just thinking of how much more could be simplified.

Last edited by ReaperX7; 11-15-2013 at 04:16 PM.
 
Old 11-15-2013, 04:22 PM   #74
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 257

Original Poster
Rep: Reputation: 87
thats correct Reaper,

It is not required, unless you build PAM.
otherwise it is an option to use or not.
 
1 members found this post helpful.
Old 11-15-2013, 04:27 PM   #75
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0, CRUX 3.1
Posts: 3,010
Blog Entries: 15

Rep: Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756
Okay, so what exact list of parts of systemd are you implementing at this time bart?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 04:57 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration