BTW, in case anyone doesn't know ... Most ironically, systemd actually improves legacy LSB Sys-V init script support over either legacy Red Hat init (RHEL5 and earlier) and Upstart (RHEL6), especially the LSB static dependency checking (although systemd adds the benefit of being far more dynamic).
So the LPI objectives should still very much include LSB Sys-V init scripts, the required and options sections, etc... even for systemd platforms. Trainers then should be focusing on the equivalents between the two (e.g., static call-outs, possibly those required for Upstart), as well as where systemd can be dynamic and auto-detect dependencies. -- bjs On Tue, Jul 29, 2014 at 2:08 PM, Bryan J Smith <b.j.sm...@ieee.org> wrote: > On Tue, Jul 29, 2014 at 10:10 AM, Alessandro Selli < > alessandrose...@linux.com> wrote: > >> Martin Møller Skarbiniks Pedersen wrote: >> >> 202.4 systemd >> Because systemd is the future and it is already default for many >> professionel distros eg. >> CentOS. >> >> This too I remember was discussed, and the outcome was that is is going >> to be introduced next exam revision IIRC. >> > > I had argued in prior years that "event" type concepts should be > introduced for Upstart and dystemd, just so sysadmins would know where to > look for the init and related paths. But now with the major Debian users > pushing their steering to adopt systemd back in January 2014, and Canonical > agreeing to respect that vote and looking to integrate it in LTS circa > 2016.4, I think it's safe to say the focus should be to add systemd by 2016. > > The major issue with systemd, and the related and often support *d > services, is that it adds far more. systemd itself is not just a > monitoring and respawning init replacement like monit or other options, but > a dynamic, D-Bus connected, socket, resource and other monitoring (for > service, resource and other dependencies) management solution for far more > than just services. So one will have to look at it's considerations beyond > just this section as well. > > E.g., I don't think people realize that system monitoring will shortly be > systemd integrated, and heavily so. That's because systemd merely, and > finally, concentrated a lot of separate, but pre-existing subsystems that > have exited in in any Linux distro for years. Subsystems which were > ignored by not only other init options, but by various, different > monitoring and other support solutions which handled some of them in > various, non-standard ways prior. systemd just finally offers a standard > way to them all now. > > -- bjs > > P.S. Martin, when I try to be general, try to use "Enterprise Linux" or > "EL" for short, instead of brand names like "CentOS" or "SL" (Scientific > Linux) or "RHEL" for that matter. Ironically I had this discussion with > one of the co-maintainers of SL, along with Red Hat associates, at Red Hat > Summit last year, with everyone defaulting to "CentOS", even on some > project sites that are wholly maintained by Red Hat. > > And yes, I know, there will be no full SL 7 release, as they are moving > to just adopt CentOS 7, with their added SL 7 repositories, given Red Hat > employs several core CentOS maintainers and has helped streamline some of > their organizational needs, including the release and configuration > management of source packages. Still, I prefer to use "EL" generically, > since no one else does (e.g., SLED/SLES doesn't). > >
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
