Is this for LPIC-2? I'd love to help out, especially on 202, 204, 209, 210 and 212 I just fear that I would be heading into more "v5" objectives.
E.g., 202: Dracut/rd.break, early systemd/journald init/troubleshooting, uEFI ESP/efibootmgr, etc... 204: nmcli, ss, etc... 209: NFS4, rpc,idmapd, rpc.secgss/AUTH_GSS, etc... 210: SSSD modules, pam_sss, etc... 212: firewalld/firewall-cmd, etc... Now, since this isn't the v5 objectives, maybe that's more 'allowable,' learning for the 'next iteration' -- call it the CBoK-"NG" maybe, which can assist in the next update, earlier rather than 'rush at the last second.' But then there will be a lot of people barking, 'Oh, that's just a distraction, they aren't tested on that, and until they are, I don't want to see any documentation of the sort on the site.' And that's before we get into the assumptions that it's only select distros (and my standard facepalm, because it's not true -- e.g., the classic "SSSD isn't on Ubuntu"). Just let me know. ;) On Fri, Mar 10, 2017 at 2:22 PM, G. Matthew Rice <[email protected]> wrote: > On Fri, Mar 10, 2017 at 12:02 PM, Ian Shields <[email protected]> wrote: >> Thanks much for your note. I read several of Adams' books many years ago >> and really enjoyed them. When I was doing a lot of sw development, I >> used to enjoy calling myself a "destruction tester". My goal was usually > > You may have helped to create a new job role: > > https://www.ministryoftesting.com/2015/03/destructive-software-testing/ > > >> The eyesight issue has definitely slowed me down a lot, but I'm not out. >> This week's doctor visit was somewhat promising in that we may have a >> way to get to improvement. t would really be nice to be able to read or >> drive again. > > Hold out for these: > > http://www.bbc.com/news/health-38391247 > > That's what I'm going to get when I need new peepers :) > > Take care, > --matt >> >> >> Nice to hear from you again. >> >> Ian. >> >> On 3/10/2017 09:09, G. Matthew Rice wrote: >>> On Thu, Mar 9, 2017 at 12:04 PM, Ian Shields <[email protected]> wrote: >>>> I've found that writing and editing takes time. If you do a group >>>> effort, you should have some standards general layout and for things >>>> like screen shots and command examples. A good template helps a lot >>>> here, but that only works to the extent that folks actually stick to it. >>>> Believe me! I wrote several versions of the IBM developerWorks XML >>>> templates and I also wrote the tools that convert MS Word and OpenOffice >>>> Writer docs to XML for dW. You wouldn't even begin to know how many ways >>>> there are to stuff up a perfectly good template unless you saw some of >>>> the stuff. >>> Hey, Ian. Nice to hear from you. You're kind of reminding me of a >>> saying that was floating around when I was doing sw development. From >>> and other sources (I just include this one because they mention >>> Douglas Adams and Towel Day is coming): >>> >>> https://en.wikipedia.org/wiki/Idiot_proof >>> "If you make something idiot proof, someone will just make a better >>> idiot." >>> >>> >>>> My series for LPIC 1 >>>> (http://www.ibm.com/developerworks/library/l-lpic1-map/) is complete for >>>> Exam 101 and in progress for Exam 102. >>> Great! I've put an updated link on the free resources pages on the wiki. >>> >>> >>>> I'm starting work again after >>>> figuring out how to deal with being legally blind, so more topics should >>>> start showing up in the coming months. When the 2016 objectives came >>>> out, I spent the first few months going through all the old tutorials >>>> and updating content for changes to objectives and changes for how >>>> various things worked. All new screen shots and all new command >>>> examples. Took a lot more effort than I had factored into my bid! Linux >>>> moves quickly. >>> Sorry to hear about your eye troubles but I'm glad that you aren't >>> letting them slow you down. Let us know if you need any help, too. >>> >>> Regards, >>> --matt >>>> >>>> Ian Shields >>>> >>>> On 3/9/2017 10:04, G. Matthew Rice wrote: >>>>> On Thu, Mar 9, 2017 at 9:49 AM, Mark Clarke <[email protected]> >>>>> wrote: >>>>>> I think the biggest challenge around on-line content is making sure it >>>>>> is not a once-off event where content goes out of date. Maybe >>>>>> organizing recurrent "hack-a-thons" for bok content would be a good idea >>>>>> especially if we can develop a community or buzz around such events. >>>>>> Something like having local or national hack-a-thons and build up to an >>>>>> annual in-person international "hack-a-thon" get-together, for a final >>>>>> push etc, to provide some community spirit and incentive to participate. >>>>> Hi Mark, >>>>> >>>>> I've started calling it a write-a-thon. Apparently, it isn't a new idea: >>>>> >>>>> http://write-a-thon.org/ >>>>> >>>>> This person has a book about writing a book in 26 days. I wonder how >>>>> long it took her to write it. :) >>>>> >>>>> So, 26 days/13 people means we have a book in a weekend, right? I >>>>> hear that one can make babies in a month this way, too... >>>>> >>>>> Having an IRL component to it would definitely make it more fun, too. >>>>> >>>>> >>>>>> I am all for on-line, continuously improving content. We should make it >>>>>> an objective that whenever the objectives are updated the content will >>>>>> be available at the same time. We need consistency though. >>>>> Agreed. We'll definitely need some editors to come along a clean things >>>>> up. >>>>> >>>>> >>>>>> BTW I am keen to participate in a week-end online hack-a-thon as put >>>>>> forward by Matthew. >>>>> Cool. Me, too :) >>>>> >>>>> PS - okay, really last post for me. >>>>> >>>>> Regards, >>>>> --matt >>>>>> On 08/03/2017 20:55, G. Matthew Rice wrote: >>>>>>> On Mon, Feb 27, 2017 at 10:03 PM, Jeremy Hajek <[email protected]> >>>>>>> wrote: >>>>>>>> Thanks for all the hard work here - I admire this serious stepping up >>>>>>>> in the >>>>>>>> LPIC standards. Recently I found that the textbooks that matched the >>>>>>>> LPIC >>>>>>> Hey, guys, >>>>>>> >>>>>>> What do you think of the idea of a 'write a book in a weekend' idea? >>>>>>> I've seen it work (almost) with other books. I think they just forgot >>>>>>> to put more effort into planning the book upfront. >>>>>>> >>>>>>> We could also make it easier by focusing on creating the Body of >>>>>>> Knowledge and forget the prose. Kind of like the start of the LPIC-2 >>>>>>> BoK at: >>>>>>> >>>>>>> https://wiki.lpi.org/wiki/LPIC-2_BoK >>>>>>> https://wiki.lpi.org/wiki/LPIC-2_BoK_Content_206.1_Make_and_install_programs_from_source >>>>>>> >>>>>>> FYI: https://en.wikipedia.org/wiki/Body_of_knowledge >>>>>>> >>>>>>> What do you guys think? A couple of us can work out the outline >>>>>>> beforehand and then meet up online for a weekend (LPI will find a nice >>>>>>> way to say thanks to the participants). >>>>>>> >>>>>>> As well, I have at least one publisher that would be interested in >>>>>>> publishing the results, too. No promises, they haven't seen what >>>>>>> they're agreeing to yet ;) >>>>>>> >>>>>>> The nice thing part of the BoK is that it provides more reference-able >>>>>>> material for all authors; books, training material, etc. >>>>>>> >>>>>>> Regards, >>>>>>> --matt >>>>>>> >>>>>>>> standards were too old to be of use so I started to write my own (it >>>>>>>> turned >>>>>>>> into a mix a LPIC 1 and 2) I finished 12 of 15 chapters (along with >>>>>>>> review >>>>>>>> questions, labs, podcast questions...) I ran out of gas (and had a >>>>>>>> third >>>>>>>> child =) https://github.com/jhajek/linux-text-book-part-1 (built in >>>>>>>> Pandoc/Markdown) >>>>>>>> >>>>>>>> Your comment Fabian, >>>>>>>> >>>>>>>> ""Good point. So far, we we have "Design software to be run in >>>>>>>> containers" >>>>>>>> in >>>>>>>> 701.1 which strives this a little. >>>>>>>> >>>>>>>> Do you think adding "Understand major differences between containers >>>>>>>> and >>>>>>>> virtual machines" to either 702.1 or 702.3 helps? 702.1 would be pretty >>>>>>>> Docker-specific, 702.3 we could allow us to cover this in a more >>>>>>>> generic >>>>>>>> way. We also have the security implications of containers as well as >>>>>>>> awareness of other container solutions (rkt) here. >>>>>>>> >>>>>>>> Bryan Canrtill the CTO of Joyent (creator of Dtrace at Sun) made an >>>>>>>> excellent presentation at Hashi Conf entitled, "The Container >>>>>>>> Revolution: >>>>>>>> reflections on the first decade." This presentation is key to >>>>>>>> understanding the difference of Containers and Virtual Machines, the >>>>>>>> best >>>>>>>> quote is: The virtual machine is vestigial abstraction. We can not get >>>>>>>> to >>>>>>>> #serverless without getting rid of of the VM. >>>>>>>> >>>>>>>> Containers indicate a titanic leap in technology (almost 1984-ian with >>>>>>>> the >>>>>>>> IBM PC and Apple Mac coming into existence, or say Windows 95 and its >>>>>>>> decade >>>>>>>> of dominance) >>>>>>>> >>>>>>>> Docker has been called the 21st century ELF format >>>>>>>> (http://slides.com/nikhilvaze/dockercon2015recap#/8). The ELF format >>>>>>>> allowed a single Linux Binary type -- the hope is that containers >>>>>>>> through >>>>>>>> Docker will be that same concept for delivering immutable applications. >>>>>>>> "Docker is doing to apt what apt did to tar" >>>>>>>> Perhaps this should be LPIC level 4 as opposed to a single subsection? >>>>>>>> >>>>>>>> I teach at the college level and am responsible for brining this tech >>>>>>>> into >>>>>>>> intro and intermediate Linux and sys admin courses. I am working >>>>>>>> through >>>>>>>> http://artofmonitoring.com with my students. James Turnbull's book on >>>>>>>> Riemann event routing platform (written by Kyle Kingsburry) using >>>>>>>> Packer to >>>>>>>> build our infrastructure and Vagrant to launch the virtual machines. >>>>>>>> It was >>>>>>>> a struggle at the beginning but I think they are coming along. Would a >>>>>>>> course like this be an LPIC 2 or 3? Or even parts of LPIC 1? >>>>>>>> >>>>>>>> What are your thoughts? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 27, 2017 at 11:00 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: lpi-examdev Digest, Vol 104, Issue 4 (Fabian Thorns) >>>>>>>>> 2. Re: lpi-examdev Digest, Vol 104, Issue 4 (Fabian Thorns) >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> Message: 1 >>>>>>>>> Date: Mon, 27 Feb 2017 11:16:23 +0100 >>>>>>>>> From: Fabian Thorns <[email protected]> >>>>>>>>> Subject: Re: [lpi-examdev] lpi-examdev Digest, Vol 104, Issue 4 >>>>>>>>> To: "This is the lpi-examdev mailing list." <[email protected]> >>>>>>>>> Message-ID: >>>>>>>>> >>>>>>>>> <CABEAHcJSM4XcJAf9Abxo7+kfcd=vqfjxmjzl5rsxhp0nknc...@mail.gmail.com> >>>>>>>>> Content-Type: text/plain; charset="utf-8" >>>>>>>>> >>>>>>>>> Hi Jeremy, >>>>>>>>> >>>>>>>>> thanks for your encouraging feedback! >>>>>>>>> >>>>>>>>> On Sun, Feb 26, 2017 at 5:05 AM, Jeremy Hajek <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I had one piece of advice. The Docker material needs to be reviewed >>>>>>>>>> because the concepts there are vastly different than Virtualization. >>>>>>>>>> Perhaps the Docker material could be its own track/specialization? >>>>>>>>>> >>>>>>>>> This depends a lot of the depth of Docker. You're right, the current >>>>>>>>> objectives are mostly about using Docker, not about configuring its >>>>>>>>> latest >>>>>>>>> detail and understand the actual containerization on a Kernel level. >>>>>>>>> If we >>>>>>>>> would like to test that, we would need to require more background in >>>>>>>>> Linux >>>>>>>>> / operating system than we currently ask the candidates of the new >>>>>>>>> exam to >>>>>>>>> have. Such an exam would probably be better off in the LPIC-3 track >>>>>>>>> since >>>>>>>>> we can expect a high level of Linux proficiency. For the LPIC-OT >>>>>>>>> DevOps >>>>>>>>> Tools Engineer, we intentionally want to keep these requirements low >>>>>>>>> to >>>>>>>>> make the effort to study the objectives reasonable for software >>>>>>>>> developers >>>>>>>>> too. How far do you get into these technical background in your >>>>>>>>> lectures? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> What I mean is traditional Virtualization which we have been using >>>>>>>>>> for a >>>>>>>>>> while now (VMware, Virtual Box, others) is essentially the same >>>>>>>>>> concepts >>>>>>>>>> as a regular PC-- its hardware virtualization (virt of a BIOS, >>>>>>>>>> Drivers, >>>>>>>>>> and >>>>>>>>>> so on) >>>>>>>>>> >>>>>>>>>> Docker (and containers in general) move to a different concept of >>>>>>>>>> immutable infrastructure--which flies in the face of all the LPIC >>>>>>>>>> base >>>>>>>>>> standards. Those needs are lessened when you are enabling containers >>>>>>>>>> that >>>>>>>>>> have no SSH even. Containers that are being spun up via AWS Lambda >>>>>>>>>> for >>>>>>>>>> instance are done so fast and then destroyed--because it is cheaper >>>>>>>>>> to >>>>>>>>>> spin >>>>>>>>>> a container up calculate something and then spin it down (much in the >>>>>>>>>> way >>>>>>>>>> you would use a function()in a programming language) . TL DR >>>>>>>>>> Containers >>>>>>>>>> (Docker) are more than just lightweight virtualization. >>>>>>>>>> >>>>>>>>> Good point. So far, we we have "Design software to be run in >>>>>>>>> containers" >>>>>>>>> in >>>>>>>>> 701.1 which strives this a little. >>>>>>>>> >>>>>>>>> Do you think adding "Understand major differences between containers >>>>>>>>> and >>>>>>>>> virtual machines" to either 702.1 or 702.3 helps? 702.1 would be >>>>>>>>> pretty >>>>>>>>> Docker-specific, 702.3 we could allow us to cover this in a more >>>>>>>>> generic >>>>>>>>> way. We also have the security implications of containers as well as >>>>>>>>> awareness of other container solutions (rkt) here. >>>>>>>>> >>>>>>>>> Let me know what you think -- and thank you for pointing this out. >>>>>>>>> >>>>>>>>> Fabian >>>>>>>>> -------------- next part -------------- >>>>>>>>> An HTML attachment was scrubbed... >>>>>>>>> URL: >>>>>>>>> http://list.lpi.org/cgi-bin/mailman/private/lpi-examdev/attachments/20170227/13b8e826/attachment.html >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> Message: 2 >>>>>>>>> Date: Mon, 27 Feb 2017 11:17:42 +0100 >>>>>>>>> From: Fabian Thorns <[email protected]> >>>>>>>>> Subject: Re: [lpi-examdev] lpi-examdev Digest, Vol 104, Issue 4 >>>>>>>>> To: "This is the lpi-examdev mailing list." <[email protected]> >>>>>>>>> Message-ID: >>>>>>>>> >>>>>>>>> <cabeahckodk-2jhxwdndwnccneqyc_2j5o5zvzubkbauuqpy...@mail.gmail.com> >>>>>>>>> Content-Type: text/plain; charset="utf-8" >>>>>>>>> >>>>>>>>> Hi Bryan, >>>>>>>>> >>>>>>>>> On Sun, Feb 26, 2017 at 5:13 AM, Bryan Smith <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> DevOps in the '10s are the move to Stateless Servers, just like >>>>>>>>>> Client-Server in the '90s was the move to Stateless Clients. >>>>>>>>>> >>>>>>>>>> No more persistent stores in Servers, just like we eliminated on >>>>>>>>>> Clients. >>>>>>>>>> That's how to focus on this, and how Containers and DevOps are >>>>>>>>>> different >>>>>>>>>> than Traditional Virtualization and it's continuing support for >>>>>>>>>> persistent >>>>>>>>>> data on Servers. >>>>>>>>>> >>>>>>>>> All true, but this not only specific to containers but also to >>>>>>>>> microservices and similar architecture patterns. In 701.1 we already >>>>>>>>> mention "how services handle data persistence". Do you think we >>>>>>>>> should be >>>>>>>>> more specific here? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Fabian >>>>>>>>> -------------- next part -------------- >>>>>>>>> An HTML attachment was scrubbed... >>>>>>>>> URL: >>>>>>>>> http://list.lpi.org/cgi-bin/mailman/private/lpi-examdev/attachments/20170227/81645b26/attachment-0001.htm >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> lpi-examdev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >>>>>>>>> >>>>>>>>> End of lpi-examdev Digest, Vol 104, Issue 6 >>>>>>>>> ******************************************* >>>>>>>> >>>>>>>> -- >>>>>>>> Jeremy Hajek >>>>>>>> Systems Architect - School of Applied Technology >>>>>>>> Industry Associate Professor of Information Technology and Management >>>>>>>> ext: 630-682-6075 (2-6075) >>>>>>>> lab: 630-682-6060 (2-6060) >>>>>>>> Main: 312-567-5291 (7-5291) >>>>>>>> cell: 630-666-1961 >>>>>>>> skype: jeremy.hajek >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> lpi-examdev mailing list >>>>>>>> [email protected] >>>>>>>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> Mark Clarke >>>>>> 📱 +2711-781 8014 >>>>>> 🌠www.JumpingBean.co.za >>>>>> >>>>>> _______________________________________________ >>>>>> lpi-examdev mailing list >>>>>> [email protected] >>>>>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >>>> _______________________________________________ >>>> lpi-examdev mailing list >>>> [email protected] >>>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >>>> >>>> >> >> _______________________________________________ >> lpi-examdev mailing list >> [email protected] >> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > > > > -- > G. Matthew Rice <[email protected]> gpg id: 0x17CF9077 > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev -- -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
