In defense of xinetd: I can tell you, that anyone who wants to install a Nagios network monitoring system will absolutely need to know xinetd. The "nrpe" daemon that gets installed on a Linux machine that's being monitored uses xinetd for both daemon startup and access control. So, until systemd takes over the world, I would favor keeping xinetd in the exam objectives.
On Tue, Jul 15, 2014 at 9:05 AM, <[email protected]> wrote: > Send lpi-examdev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of lpi-examdev digest..." > > > Today's Topics: > > 1. Re: Status of LPIC-1, LPIC-304 and Linux Essentials > Objectives (Marc Baudoin) > 2. Re: Status of LPIC-1, LPIC-304 and Linux Essentials > Objectives (Anselm Lingnau) > 3. Re: Status of LPIC-1, LPIC-304 and Linux Essentials > Objectives (G. Matthew Rice) > 4. Re: Status of LPIC-1, LPIC-304 and Linux Essentials > Objectives (Anselm Lingnau) > 5. Re: Status of LPIC-1, LPIC-304 and Linux Essentials > Objectives (Alessandro Selli) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 15 Jul 2014 14:48:50 +0200 > From: Marc Baudoin <[email protected]> > Subject: Re: [lpi-examdev] Status of LPIC-1, LPIC-304 and Linux > Essentials Objectives > To: "This is the lpi-examdev mailing list." <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > G. Matthew Rice <[email protected]> ?crit : > > On Tue, Jul 15, 2014 at 5:34 AM, Marc Baudoin <[email protected]> > wrote: > > > So I'm going to break the silence. > > > > But on the day that we're supposed to go from draft to released? I'm > > gonna get you for this. ;) > > Was there a calendar? Sorry about that. Remind me next time we > meet so I can apologize with the correct amount of beers ;-) > > > > I've already said that a few years ago but the order of the > > > objectives is not logical. > > > > Agreed. But I'll let the other responses cover that. > > I give up on that. > > > > In 103.1, . and source would make more sense in 105.2. > > > > I think that it would better in 105.1 (ie. for sourcing bashrcs and > > login/logouts). And revisited in 105.2 (or left as an 'aha' moment). > > > > Opinions? I've moved it to 105.1 until I hear otherwise from people. > > 105.1 is OK too (at least better than 103.1). > > > > Is exec > > > really useful (if it is, I would also suggest to move it to > > > 105.2)? > > > > Yes, it's useful. Why have a shell process kicking around when you > > really want something else to take over. > > > > Plus, I find using exec to redirect file descriptors very useful. > > This isn't the best article/forum post on the matter but it > > illustrates my point: > > > > > http://unix.stackexchange.com/questions/18899/when-would-you-use-an-additional-file-descriptor > > > > I don't think that we cover this aspect of exec in the LPI exams, though. > > > > I think that you're right about it being in 105.2, though. Doing an > > exec on the command line isn't usually what someone wants. > > It could be a good joke. > > > > In 103.2, is the pr command (designed for matrix printers, which > > > are seldom used today) really useful? I also doubt expand, fmt, > > > join, paste, split and unexpand are heavily used. On the other > > > hand, more and less are useful filters, which are not listed > > > here. > > > > hilarious. We've missed less on that list for years. I've added it. > > Thanks. > > > Personally, I use(d) pr. Although, I'm more likely to use enscript > > nowadays but I don't think that we should cover that. > > enscript or a2ps. But I agree they're not relevant here. > > > And fmt is pretty handy when you want to make your paragraphs look > > nice. I use fmt in vi all the time I should probably make a map for > > it. > > I use Vim and gqap (which does the same thing but without forking > a process). > > > > In 103.3, xz should be added to the list of compression programs. > > > > Added. > > Thanks. > > > > The title for topic 102, "Linux Installation and Package > > > Management", is not accurate. Linux installation is not dealt > > > with. > > > > Isn't 102.1 (designing hard disk layouts) and 102.2 (installing a boot > > manager) part of doing a Linux install? > > Of course but 102.1 and 102.2, if I'm not mistaken, focus on the > manual part of things. > > > > I still find it hard to deal with shared libraries with people > > > with no knowledge of C programming. Let's face it, most systems > > > administrators nowadays know nothing about C and the POSIX API, > > > which also makes their understanding of the operating system much > > > more superficial. Does the 102.3 subtopic, with only 1 question > > > in the exam, needs to be maintained here? It would make much more > > > sense in 201. > > > > I'd vote 'yes' to keeping it. IMO, it's essential knowledge. And > > dropping it to move it to 201 would mean a 4 year window (our next > > major update to LPIC-2) where it isn't covered at all. > > > > What about the use case where someone wants to download something new > > and try it out in their user account? Especially, something that > > hasn't been packaged for them. > > So sad people don't use the source code anymore. Everybody is > boasting they're doing open source stuff but nobody uses the > source anymore. > > But I see your point. > > > > Enough for 101, let's move to 102. > > > > > > In 105.1, /etc/bash.bashrc is missing in the awfully long list of > > > bash configuration files > > > > Added. > > Thanks. > > > > In 106.1, should xhost still be covered given its coarse > > > security? Basic knowledge of xauth should replace it, knowing > > > that ssh -X automatically does everything necessary. > > > > I think that most people would argue for less X in general for the > > exam. I have a soft spot for it, though. Porting X11R5, Motif and > > CDE to a new platform was my second job out of university (a long time > > ago ;)). > > Don't tell. That was when people used to compile X (see above). > I also remember downloading X11R6 the day it got released and > compiling it on a Sun SparcStation. Sigh... > > > > 109.4 should immediately follow 109.2 and so > > > /etc/resolv.conf, /etc/hosts and /etc/nsswitch.conf should not be > > > covered in 109.2. > > > > hosts + nsswitch.conf (hosts: files ...) != DNS > > Well, it's not but it's pretty close. > > > > In 110.2, shouldn't inetd and xinetd be removed? I think they > > > haven't been used by default on any distribution for quite some > > > time now. Standalone daemons are the default now (even if I > > > still launch my UW IMAP from inetd, but that's me). > > > > It's still around and important stuff. Plus, some people use LPIC-1 > > (particularly) as a Unix certification. > > BSD systems still come with inetd by default (I'm a huge user of > NetBSD, I can tell for this one) but it's still rarely used > because most daemons are standalone. > > > How about we wait until the next update. By then systemd will have > > subsumed everything > > Or not... > > http://boycottsystemd.org/ > > > and we can decide on whether it should replace the (x)inetd > > coverage? :-D > > Why not. > > > Thanks, Marc. These were great comments. > > You're welcome. > > -- > Marc Baudoin > Linagora formation - responsable p?dagogique > http://formation.linagora.com/ > > La pr?sente transmission contient des informations > confidentielles appartenant ? Linagora, exclusivement destin?es > au(x) destinataire(s) identifi?(s) ci-dessus. Si vous n'en faites > pas partie, toute reproduction, distribution ou divulgation de > tout ou partie des informations de cette transmission, ou toute > action effectu?e sur la base de celles-ci vous sont formellement > interdites. Si vous avez re?u cette transmission par erreur, nous > vous remercions de nous en avertir et de la d?truire de votre > syst?me d'information. > > The present transmission contains privileged and confidential > information belonging to Linagora, exclusively intended for the > recipient(s) thereabove identified. If you are not one of these > aforementioned recipients, any reproduction, distribution, > disclosure of said information in whole or in part, as well as > any action undertaken on the basis of said information are > strictly prohibited. If you received the present transmission by > mistake, please inform us and destroy it from your messenging and > information systems. > > > ------------------------------ > > Message: 2 > Date: Tue, 15 Jul 2014 14:54:59 +0200 > From: Anselm Lingnau <[email protected]> > Subject: Re: [lpi-examdev] Status of LPIC-1, LPIC-304 and Linux > Essentials Objectives > To: [email protected] > Message-ID: <2722154.aZKB2N1a5O@ceol> > Content-Type: text/plain; charset="utf-8" > > Matt Rice wrote: > > > > In 103.1, . and source would make more sense in 105.2. > > > > I think that it would better in 105.1 (ie. for sourcing bashrcs and > > login/logouts). And revisited in 105.2 (or left as an 'aha' moment). > > > > Opinions? I've moved it to 105.1 until I hear otherwise from people. > > OK ? > > > Yes, it's useful. Why have a shell process kicking around when you > > really want something else to take over. > > It is useful and takes about one minute to explain (two with a > demonstration). > Let's keep it in. > > > Personally, I use(d) pr. Although, I'm more likely to use enscript > > nowadays but I don't think that we should cover that. I'm okay with > > dropping it if we can get a 'second' from someone on this nomination. > > I usually spend some time (a few minutes) on pr(1), not because it is a > tool I > think everybody should use all the time, but because it is a good > illustration > for the sort of thing one can accomplish with pipelines. It does come in > handy > every so often, though. > > > Also, personally, I use expand on other people's source code quite > > often. Mixed spaces/tabs are really annoying when people don't use > > the right tabstops. ;) > > Seconded. > > > And fmt is pretty handy when you want to make your paragraphs look > > nice. I use fmt in vi all the time I should probably make a map for > > it. > > Seconded. > > > > The title for topic 102, "Linux Installation and Package > > > Management", is not accurate. Linux installation is not dealt > > > with. > > > > Isn't 102.1 (designing hard disk layouts) and 102.2 (installing a boot > > manager) part of doing a Linux install? > > > > Arguable, so is managing shared libraries when you're installing > > (additional) software. > > We haven't covered Linux installation in the strict sense in our classes > for a > very long time, because (a) how to do it is distribution-specific, and (b) > it > isn't exactly rocket science ? if you pop in the CD (or USB stick) and keep > hitting RETURN you will usually end up with a reasonable Linux system. > > I agree that hard disk layout is something worth covering, simply because > it > is easy for people to shoot themselves in the foot. I don't know who still > does detailed boot manager configuration these days (other than people > compiling their own kernels, which would suggest that the topic might > eventually move to LPIC-2). > > > [Shared libraries] > > I'd vote 'yes' to keeping it. IMO, it's essential knowledge. And > > dropping it to move it to 201 would mean a 4 year window (our next > > major update to LPIC-2) where it isn't covered at all. > > > > What about the use case where someone wants to download something new > > and try it out in their user account? Especially, something that > > hasn't been packaged for them. > > Yes, because it takes all of a five-line C program to demonstrate most of > what > there is to demonstrate about static vs. shared libraries. If people can't > sort-of grok a five-line C program if it is explained to them, even if they > haven't seen C before, they have no business doing LPI exams. It's not as > if > we're asking them to write configure.in files. > > > [bash vs. zsh] > > Agreed. At least for command line use. I still use bash for > > scripting, though. Least common denominator and all. Actually, I > > just switched from #!/bin/sh to #!/bin/bash a year or two ago for all > > script writing. I've had it with having to remember when I started using > > bashisms in my scripts. > > We explain /bin/bash vs. /bin/sh and the caveats involved. We mention the > existence of other shells but don't go into detail. > > > I think that most people would argue for less X in general for the > > exam. I have a soft spot for it, though. Porting X11R5, Motif and > > CDE to a new platform was my second job out of university (a long time > > ago ;)). > > X11 used to be a huge problem back when one would have to figure out one's > monitor timings in order not to fry one's display. In previous reviews of > the > exam, the level of X knowledge required has been downgraded again and > again, > and as far as I am concerned that trend should continue. For example, I'd > kick > out all the display manager configuration details in favour of more > high-level > knowledge (i.e., what is Wayland and why is it interesting?). > > > > In 107.1, vipw is dearly missing... > > > > I believe that vipw (and vigr) were in the objectives but dropped a > > few years ago to keep vi from creeping into the 102 exam. Although, > > the EDITOR environment variable will fix that problem for the > > vi-challenged. > > > > Isn't this where usermod/groupmod come in, though? > > Imagine you're rearranging the /home layout for your 200-user file server. > Personally I'd prefer using ?:s///? in vipw to 200 calls to usermod (even > in a > shell loop). The latter is still an improvement if you'd otherwise have to > use > a GUI, but even so ? > > (vipw/vigr have been part of our training materials from the very > beginning.) > > > We're getting into distro specifics here (albeit, prevalent ones). > > I'm not against adding them at an "awareness" level but I don't think > > that we need to cover the innards. > > > > Opinions anyone? > > In our training materials we go over the network configuration files for > the > most important Linux distributions. I'm not sure detailed knowledge of > their > content belongs in the exam, though. > > > [inetd/xinetd] > > How about we wait until the next update. By then systemd will have > > subsumed everything and we can decide on whether it should replace the > > (x)inetd coverage? :-D > > Agreed. > > Anselm > -- > Anselm Lingnau ... Linup Front GmbH ... Linux-, Open-Source- & > Netz-Schulungen > [email protected], +49(0)6151-9067-103, Fax -299, > www.linupfront.de > Linup Front GmbH, Postfach 100121, 64201 Darmstadt, Germany > Sitz: Weiterstadt (AG Darmstadt, HRB7705), Gesch?ftsf?hrer: Oliver Michel > > > ------------------------------ > > Message: 3 > Date: Tue, 15 Jul 2014 09:01:01 -0400 > From: "G. Matthew Rice" <[email protected]> > Subject: Re: [lpi-examdev] Status of LPIC-1, LPIC-304 and Linux > Essentials Objectives > To: "This is the lpi-examdev mailing list." <[email protected]> > Message-ID: > <CAFKQHHPSbnEJ3jZT7Oiybgi3PjLoS7UGQUq= > [email protected]> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Jul 15, 2014 at 8:48 AM, Marc Baudoin <[email protected]> > wrote: > >> Isn't 102.1 (designing hard disk layouts) and 102.2 (installing a boot > >> manager) part of doing a Linux install? > > > > Of course but 102.1 and 102.2, if I'm not mistaken, focus on the > > manual part of things. > > Sure but the concepts are important for doing installs. And full > blown installs are beyond the scope (and too distro specific) to > cover. So, we cover some important parts of doing an install instead. > > > >> How about we wait until the next update. By then systemd will have > >> subsumed everything > > > > Or not... > > > > http://boycottsystemd.org/ > > I don't have a strong opinion either way but this sure seems to be > swimming against the tide. > > Regards, > --matt > > -- > G. Matthew Rice <[email protected]> gpg id: EF9AAD20 > > > ------------------------------ > > Message: 4 > Date: Tue, 15 Jul 2014 15:13:30 +0200 > From: Anselm Lingnau <[email protected]> > Subject: Re: [lpi-examdev] Status of LPIC-1, LPIC-304 and Linux > Essentials Objectives > To: [email protected] > Message-ID: <8080906.X9WByDppmf@ceol> > Content-Type: text/plain; charset="utf-8" > > Matt Rice wrote: > > > > http://boycottsystemd.org/ > > > > I don't have a strong opinion either way but this sure seems to be > > swimming against the tide. > > These people are circling the wagons but the caravan has long since moved > on. > > Most of their objections are easily debunked, anyway, simply by studying > the > systemd docs. Three years from now nobody will remember any of this. > Besides, > these objections (overengineering, gratuitous new interfaces, blasphemy > against the Unix philosophy, ?) are exactly the ones that people brought > forward when SysV init was new in the 1980s ? and now SysV init is > supposed to > be the best thing since sliced bread? > > Anselm > -- > Anselm Lingnau ... Linup Front GmbH ... Linux-, Open-Source- & > Netz-Schulungen > [email protected], +49(0)6151-9067-103, Fax -299, > www.linupfront.de > Linup Front GmbH, Postfach 100121, 64201 Darmstadt, Germany > Sitz: Weiterstadt (AG Darmstadt, HRB7705), Gesch?ftsf?hrer: Oliver Michel > > > ------------------------------ > > Message: 5 > Date: Tue, 15 Jul 2014 15:12:42 +0200 > From: Alessandro Selli <[email protected]> > Subject: Re: [lpi-examdev] Status of LPIC-1, LPIC-304 and Linux > Essentials Objectives > To: "This is the lpi-examdev mailing list." <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > G. Matthew Rice wrote: > > On Tue, Jul 15, 2014 at 5:34 AM, Marc Baudoin<[email protected]> > wrote: > [...] > > > >> In 103.1, . and source would make more sense in 105.2. > > I think that it would better in 105.1 (ie. for sourcing bashrcs and > > login/logouts). And revisited in 105.2 (or left as an 'aha' moment). > > > > Opinions? I've moved it to 105.1 until I hear otherwise from people. > > I agree. > > >> Is exec > >> really useful (if it is, I would also suggest to move it to > >> 105.2)? > > Yes, it's useful. Why have a shell process kicking around when you > > really want something else to take over. > > > > Plus, I find using exec to redirect file descriptors very useful. > > This isn't the best article/forum post on the matter but it > > illustrates my point: > > > > > http://unix.stackexchange.com/questions/18899/when-would-you-use-an-additional-file-descriptor > > > > I don't think that we cover this aspect of exec in the LPI exams, though. > > > > I think that you're right about it being in 105.2, though. Doing an > > exec on the command line isn't usually what someone wants. > > I usually use it when I run su on remote terminals, to make sure I > won't leave around an idle network login when I exit just once. > > [...] > > >> I still find it hard to deal with shared libraries with people > >> with no knowledge of C programming. Let's face it, most systems > >> administrators nowadays know nothing about C and the POSIX API, > >> which also makes their understanding of the operating system much > >> more superficial. Does the 102.3 subtopic, with only 1 question > >> in the exam, needs to be maintained here? It would make much more > >> sense in 201. > > I'd vote 'yes' to keeping it. IMO, it's essential knowledge. > > I think the same way. > > [...] > > >> In 109.2, configuration files (/etc/network/interfaces, > >> /etc/sysconfig/network and > >> /etc/sysconfig/network-scripts/ifcfg-*) should be covered (they > >> are used by ifup, which is in the objectives). > > We're getting into distro specifics here (albeit, prevalent ones). > > I'm not against adding them at an "awareness" level but I don't think > > that we need to cover the innards. > > > > Opinions anyone? > > To me it looks like the same situation as per the package install > commands: rpm and yum vs. dpkg* and apt*. On one side, they are > distribution specific, but not to a single distribution, rather to a > family of like, widespread distributions. If we do cover > /etc/sysconfig/network* RH stuff, we should also cover /etc/network/* DB > stuff (I actually think covering just /etc/network/interfaces suffices). > > >> 109.4 should immediately follow 109.2 and so > >> /etc/resolv.conf, /etc/hosts and /etc/nsswitch.conf should not be > >> covered in 109.2. > > hosts + nsswitch.conf (hosts: files ...) != DNS > > > > I did drop resolv.conf from 109.2, though. It is DNS. > > 109.1 "Fundamentals of internet protocols" lists port 53 (domain) in the > "Knowledge about common TCP and UDP ports" section, though. > > [...] > > > If anyone made it this far, let me know if you have a problem with any > > of the changes. > > No problem. The proposed changes sound reasonable. > > > Alessandro > > > > ------------------------------ > > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > End of lpi-examdev Digest, Vol 81, Issue 5 > ****************************************** >
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
