G. Matthew Rice wrote: > On Wed, Jun 19, 2013 at 6:09 PM, Alessandro Selli > <[email protected]> wrote: >> 1) extended file attributes (chattr and lsattr); > chattr was dropped from LPIC-1 back in 2008/9 (or whenever these > changes were made): > > http://wiki.lpi.org/wiki/LPIC1AndLPIC2SummaryVersion2To3 > > probably because the rest of the *attr material wasn't included (I > think everyone just cared/knew/understood chattr +i at the time ;)).
I do not usually cover *attr commands, however the class I'm having now is a 'special' one: they are embedded Windows programmers who now need to learn to code in Linux and they know nothing of it. They are not much interested in getting certified, they rather want to learn what they want/feel they need knowing. This means that when they ask me "How do I do this or that", "What is this or that?" I've got to fully explain them what they want, even if this or that is not part of the LPIC objectives(*). Because they know nothing of Linux this seldom happens, however one of such questions was how can one protect files from being overwritten, and there the chattr command fit in. I thought this would take just a minute, but then I had that error message I did not expect, and the single minute become fifteen and then I also had to tell them about the Linux Capabilites. >> 2) Linux Capabilities (getcap, setcat, cap_from_text etc.). > Whew! Is this LPIC-1 material? We are going to be updating LPIC-1 > next year, I'm fairly sure (it's time). I do not consider it LPIC-1 material, I just needed to tell them about it for the reasons explained above. I think putting them in LPIC-2 would be more appropriate. And I think that a passing mention of extended FS attributes would be a nice dressing to it, but if they were rejected by a large majority and for solid reasons I'm not going to nag about it. I just think that it would take a bare minute telling people that: 1) there are more attributes than ls or stat show you; 2) they can be seen with lsattr and set/uset with chattr; 3) the really useful and fully implemented/supported ones are the immutable and append-only attribs; 4) for a full list of supported attributes see man chattr(1). > That would be the time to make the case to re-add chattr plus everything else. I understand they are seldom used, but the few times one needs them they are indeed a boon. And a cheap one, too. >> Regarding point (1), I consider their apt place to be 104.5 "Manage >> file permissions and ownership". > Or a new objective on linux caps and everything you mentioned above? > Someone has mentioned that more 'security' in LPIC-1 could be a good > thing. Maybe they're right, it does make sense putting them into LPIC-1 instead of LPIC-2. They are not that advanced commands, they look like just like chmod or chown. >> I also would like to know if there is any plan to switch the "205.1 >> Basic networking configuration" objective from the old style, >> wireless-tools commands (iwconfig) to the new style (iw) tools. > That's a good point. We should either switch or include both. And be > explicit in the objectives. At first I thought that the first move ought to be to have them both, clearly identifying the wireless-tools commands as dinosaurs and the iw command as the new breed and king of the wireless realm. However I noticed that even Debian stable no longer has wireless-tools, and covering them too could lead to a unnecessary overcrowding of 205.1. > With the November 1st, release of the exams/objectives, we have a > little bit of time to decide but not much. The courseware/book > authors are getting antsy. > > That said, I just checked my most recent install. It's an XXX LTS > version (don't judge me, it's a phase I'm going through). Both iw* > and iw are installed. Perhaps an 'awareness of iw' is warranted > instead of a wholesale switch over. The other thing to keep in mind > is that this objective isn't stressing wireless. Which is why only > iwconfig and iwlist are included. Adding just 'iw' could have people > misconstrue the extent of the wireless coverage. > > Opinions on this matter, if done soon, would be useful. I understand that wireless could easily get out of hand, because there is more to keep in mind than plain ethernet configuration (ESS versus IBSS, channels, signal strength, country regulations, authentication, ...), but I do see more and more people not only using some WiFi-ready Linux apparatus (even Arduino now has it), but they are starting to take it for granted. I think we ought to consider it worthy of coverage, no matter how stripped-down. _____________________________ Notes: *) I know very well that when I hold LPIC-1 classes I am not a generic Linux educator, but a Linux Professional Certification trainer, and that LPI is not about educating people to Linux, but to test their knowledge in specific professional fields. However "the customer is (basically) always right", expecially when the Management agrees with him/her. > Regards, > --matt >> >> Regards, >> >> >> -- >> Alessandro Selli >> Tel: 340.839.73.05 >> http://alessandro.route-add.net, VOIP: sip:[email protected] >> Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9 >> _______________________________________________ >> lpi-examdev mailing list >> [email protected] >> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > > -- > G. Matthew Rice <[email protected]> gpg id: EF9AAD20 > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev -- Alessandro Selli <[email protected]> Tel. portatile: 340.839.73.05 VOIP SIP: [email protected] Sito web: http://alessandro.route-add.net/ Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9 _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
