Let's qualify these things. To me, I see at least 3 questions of
which the answer must be "yes" to _all_ to include ...
1. Is it a sysadmin duty at the level (e.g., LPIC-1=junior)?
2. Can we write real-world tasks for the duty?
3. Can we pin down the implementation/limitations of the tasks?
Here are some samples under consideration ...
A. Local software installation
B. Network software management
C. SQL coding
D. SQL service management
A. Locla software installation
1. Yes
2. Yes, how to build and/or install software
3. Yes, DPKG, RPM and source
B. Network software management
1. Yes
2. Yes.
3. Possibly and no, Possibly to APT, YUM and even Portage
clients. No to APT, YUM, Portage back-ends (too deep), no to
software-specific distribution (e.g., Perl/CPAN, etc...). I think
the latter should be a LPIC-2 or even a specific LPIC-3 ECM
(enterprise configuration management) exam.
C. SQL coding
1. No ('nuff said)
D. SQL service management
1. Yes
2. Maybe
3. Probably not, too many to consider.
I can see pairing down DPKG and/or RPM and/or source. Getting into
APT and/or YUM and/or Portage is more difficult. Going beyond simple
client access/commands is definitely hard and deep, with ECM
considerations and "Best Common Practices" (BCP).
I actually do more SQLite or Berkeley Sleepycat DB stuff than MySQL
or PostgreSQL anymore, as a lot of software I use have embedded DBs
such as the former, instead of services such as the latter. SQLite
and PostgreSQL are already widely different, more so than ... say ...
DPKG and RPM, more like DPKG/RPM v. source. And APT and YUM are more
similiar than, say, Portage. And we're still ignoring a lot of
approaches, from Slackware TGZ and SlackAPT to SmartPM, etc... on the
packaging front.
If you can qualify your argument for/against #3, I'd say it's either
a good/poor candidate for inclusion on a LPI exam, respectively. I
don't see SQL service management being something we can "pin down,"
even if SQL is a common "killer app" on Linux servers.
-- Bryan J. Smith, LPIC-2
DISCLAIMER: My postings to LPI lists do not represent an
acknowledgement or endorsement of LPI by my employer or as a part of
my employment.
--
Bryan J. Smith Professional, Technical Annoyance
[EMAIL PROTECTED] http://thebs413.blogspot.com
--------------------------------------------------
Fission Power: An Inconvenient Solution
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
