Hi there,
As a trainer, my worst problem with LPIC2 is the lack of time. It's by far my preferred training but I'd love it even more if some changes were made. Usually we only have from 60 to 80 hours to teach it all (201 & 202). Last years we kept on adding new content: LDAP administration (after dropping 301) + iSCSI & nginx + .... Some bits got removed but at the end I need more time to teach-it-all than 10 years ago (~90-100h if you want to be able to do labs for all topics). Right now I see LPIC-2 as a 3 blockS-training: - 201: Core-stuff-you-do-locally-on-your-servers ( Kernel, Hardware, System Startup, PAM, RAID, LVM...). That is useful, it must be there but it's not a bestseller and maybe it's time to get rid of Kernel compilation. I think my students are amongst the few human beings compiling a Kernel nowadays... 20 years ago you needed it. Right now ... - 202-A: Stuff you do on your LAN: ( Samba, NFS, Squid Proxy, DNS-Cache... ). - 202-B: STUFF YOU DO ON THE INTERNET: ( DNS, FTP, Web, Netfilter, Email... ). <--------------------- IMHO, tHIS CERTIFICATION BEST SELLING POINT IMHO people likes "Internet Services" way more than LAN services. At least here in Spain, "LAN services" are useless to most of my students. The majority of them are either cloud-sysadmins, corporate-sysadmins (so no chance to use Samba or Squid around), devops (they simply don't care about LAN, everything is on the Internet) or Operators/jr-sysadmins that want to become sysadmins. Probably less than 15% of them work on a SMB or a company providing services to SMBs. It should be nice to do a poll on this, asking former LPIC-2 students what were they missing / what has been useless to them. I'd suggest to stop adding more contents to LPIC2 and create "tiny courses/certifications" that complement LPIC-2's track instead. In fact I'd shorten LPIC-2 a bit. This way we could extend "Internet Stuff" with Mod-Rewrite, more Nginx, PHP-FPM, HAProxy and Opensource Databases ( SQL & No-SQL ) whilst keeping it below 100hr. Academies prefer 30-40h trainings, easier to sell than a 80-100h, and LPIC2 is hard to sell right now. Adding all that cloud-compatible stuff could help making it more popular. "LAN services" could be moved into 300, including FreeIPA and Samba4. By focusing on really core topics we could keep it below 60h, I like having Email services on LPIC2, but teaching how to configure postfix & dovecot (&courier!!!!!!) without any real backend (SQL or LDAP), no control panel and no antispam&antivirus is not very useful. Definetly it deserves it's own LPIC-3 (as planned some years ago), but I don't think it's going to be a bestseller. Probably it would be the least successful of all, but you need to show at least configure a control panel, webmail, antispam&antivirus, RBLs, SPF, DKIM, D-MARC, SMTP ICMP&DNS requirements .... So, it's own 25-30h training. We could leave it only as an internet-relay and we'd be covering the scenario of 99% of our students. However, being honest, few people will ever ask about LPIC-3-Email. So far, I only know about some public administration handling 30.000+ accounts, as well as some Hosting companies. That's less than 10% of my students (and I train dozens of public workers every year). Regards, Kenneth A 2018-11-16 18:08, Ortwin Ebhardt escrigué: > Hello Bear, > > I can only speak for myself; I come from a company provding Linux > Adminstration and Implementation Services for a variety of customers. From my > experience and from what I think the LPIC-2 is about I do not agree with you > on most of the topics. I'll explain it in your text. (I see it from an > administrator perspective - after all, the LPIC-2 is a certification for > administrators. To qoute from the LPI.org-Site: "The LPIC-2 will validate the > candidate's ability to administer small to medium-sized mixed networks.") > > ---------------------------------------------- > > FTP vs. Databases > > Some customers still use traditional FTP servers but everyone has a database. > Usually multiple ones - different versions, different authentication > mechanism, etc. Since there's a limited number of questions I think there > will be more value in asking questions about database configuration than ftp > server configuration. > ---------------------------------------------- > While the number of customers woning FTP is decreasing, there are still a lot > of them. FTP and TFTP Servers are still crucial for some tasks (like firmware > updates for switches). So I think it is very crucial to administrators to > know about the implementation. > I agree that virtually every customer has a database - much more than one. A > bit of basic knowledge about databases should be (and is,a s I remember) part > of LPIC-2. But to go further into it would be difficult; which database > should it be - MariaDB, MySQL, Oracle... to name some. And - after all, > LPIC-2 is not about databases, it is about Linux Administration. > Nevertheless it may be worth a thought to implement a database-oriented LPIC > - I think the need for that is there. > > ----------------------------------------------- > Email > > Email is similar. Many sites still run their own servers but it's incredibly > common for sites to use hosted accounts at gmail or outlook. People still > need to know how to configure their servers to forward email to these sites. > On my personal systems I can use an application-specific password but that > couldn't scale to any extent unless all servers used the same password or the > satellite systems all forward mail to a handful of forwarders that have those > application-specific passwords. > > Also - anti-spam measures like SPF and DKIM. I'm probably biased here but I > would prefer to see a question on this (what is it, how to configure your DNS > entry to support it, what are the concerns when you use a scalable cloud > solution where email could come from previously unknown IP addresses, etc.) > ----------------------------------------------- > Here I partly agree regarding antispam. Though it may be a bit much for > LPCI-2. Mailservers on the other hand are still needed - Linux Admins should > be able to do a basic configuration, as it is often needed. It may be usefull > to turn it down a bit in LPIC-2, because if I remember correctly there where > thoughts about an LPIC-3 with Mail as a main toppic - but I may be wrong > here. > > ----------------------------------------------- > > Authentication > > This may be our biggest pain point. Kerberos is huge now that we're moving > into the Hadoop ecosystem. There's the basics - setting up a KDC, using LDAP > as a backend to KDC and also using LDAP to provide user and system public > x.509 keys, basic kadmin, what the / means in the principal name, what user > impersonation means, how HDFS can support hdfs/_HOST@REALM instead of a > specific host principal, etc. Some of our customers are moving to 'kerberos > everywhere' policies so even servers that didn't traditionally use kerberos > are starting to now. That means traditional databases, ssh, etc. > > OAuth is a second pain point when integrating to many web services. Part of > that is because OAuth is a very loose standard and everyone is different but > part of it is the need to be able to maintain a public callback point, to > know how to refresh a token once, etc. There could easily be a question on > setting up your own OAuth system, configuring servers to accept it, > supporting clients that are programs, not people, so you have fewer options > when authenticating to the third party that vouches for you. > > There's still a need for an LPIC-3 specialization but it's impossible to do > much of our work with the ability to work with kerberos and oauth. > ---------------------------------------------------- > Well, as our customers do not need it, I can only guess, but I think here you > are right. > > ---------------------------------------------------- > AWS, docker, kubernetes > > Many companies now use AWS extensively or even exclusively. You don't want to > duplicate the AWS certs but there's a good chance that the new system you > need to add a server to is running on EC2 or a virtual environment instead of > traditional hardware. That moots many of the issues in 201 and 202 since you > don't control the hardware, you don't control the IP address allocation > (DHCP), and you probably don't control the routing via the traditional > methods. Many sites will use Route 53 instead of running their own DNS server > - they'll need to know how to set up zone files but won't need to know the > details of bind. > > In our dev work we usually use EC2 instances but some devs use a virtualbox > instance and oursoft goal is Kubernetes with a relatively small set of base > docker images and final configuration via ansible. The k8s cluster may be on > local hardware or EC2 instances - the sysadmin will need to know how to > maintain each but the devs won't care. > ----------------------------------------------------- > It may be that many customers use cloud services. Depending on the provider > it still may be neccessary to configure the virtual hardware. Nevertheless, > most of our customers use systems in their own environment. The LPIC-2 should > reflect (again - in my opinion) the ability of a linux administrator to > configure and run such a linux environment. So it is absolutely crucial to > have knowledge about those configurations. (Esecially as it is basic > knwoledge needed to set up a docker system.) > > ----------------------------------------------------- > I know there's an LPIC-3 test on this but again I would argue that these > technologies are now so common that any senior sysadmin should have as much > confidence in setting up these environments as setting up an environment in a > data center when given the configuration details by an LPIC-3 type person. > > Puppet, Chef, Ansible, Salt > > With scalable solutions sysadmin tasks have to be automated - AWS etc can > automatically add or remove hundreds or thousands of servers. You can't > manage them manually and even if you did you would make errors. Hence the > initial push for these solutions. Once you've done that it naturally extends > to all of your sysadmin tasks. > > That's my personal pain point as we start to integrate the work. With > long-lived instances I can do everything manually. With a solution where we > might bring up an instance for less than an hour in order to run some tests > it has to be automated. In our case we use ansible. I expect the final > process will be doing it once manually, to understand all of the variables, > then capturing it in an ansible playbook. > > I know that you can create your own base images for EC2 and specify some > commands to run at startup. That's great if you're pure AWS but doesn't help > if you're using a mix of EC2 and virtual machines so I would put that in an > LPIC-3 topic or leave it to the AWS certs. > ------------------------------------------------------- > I think the LPIC-2 is not the right place for that - though a bit of > automation would not be bad. > > ------------------------------------------------------- > I hope this doesn't sound too much like sour grapes after my low test scores > - I know I know my stuff, it's just figuring out the gaps between that and > the requirements of a sysadmin in a traditional data center. I just wanted to > give you the perspective from someone who needs to be able to independently > set up a large variety of servers but relies on others for the platform > itself. > > ------------------------------------------------------- > I think it does not sound like that... But I wonder if the LPIC-2 is the > right certification here. There is an LPI devops - may be that would be a > much better choice, as it should deal with at least some of the point you > mention. > As I mentioned above, this is my very own opinion based on my understanding > of the LPIC-2 certification. May be we have different expectations about it. > I hope I did not insult you on any level - if so, I appologize, as it is not > my intend. > > Best regards, > Ortwin > > Ortwin Ebhardt > > Senior Consultant > > Capricorn Consulting GmbH > An Krietes Park 6 > 28307 Bremen > > Telefon: +49 421 98981-642 > > E-Mail: [email protected] > > Internet: www.capricorn.de [1] > > Jetzt neu: IT News von Capricorn. Kompakt - Aktuell - Direkt. Anmeldung unter > www.capricorn.de [2] > > Geschäftsführer: Thomas Bargfrede, Dipl.-Ing. Axel Buschmann, > Thomas von Massenbach, Thomas Heuermann > Registergericht: Amtsgericht Bremen, HRB 31421 > > Unsere Informationspflicht nach Art. 13 DSGVO finden Sie hier [3] > > HINWEIS > > Diese elektronische Nachricht ist vertraulich und ausschließlich für den > Adressaten bestimmt. Falls Sie nicht der beabsichtigte Empfänger der > Nachricht sind, ist jede Veröffentlichung, > Vervielfältigung, Verbreitung oder Nutzung des Inhalts der Nachricht verboten. > Falls Sie die Nachricht versehentlich erhalten haben, informieren Sie die > Capricorn Consulting GmbH bitte > unverzüglich telefonisch oder per E-Mail. > > This electronic mail is intended to be for the use of the individual or > entity named above. If you are not the intended recipient of the information, > be aware that any disclosure, copying, > distribution or use of the contents of this information is prohibited. If you > have received this electronic mail in error, please notify the Capricorn > Consulting GmbH by telephone or email. > > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev [4] Links: ------ [1] https://www.capricorn.de/ [2] http://www.capricorn.de [3] https://www.capricorn.de/datenschutz-kurz.html [4] 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
