Another peek into the thought processes of a newbie learning how to be a sysadmin. My project: install zikula with 2 plugins on a test server. This took me 14 minutes to do on my own laptop; let's see how long it takes me to figure out how to do the same thing on Fedora Infrastructure's publictest6 machine. Go!

Part 1: Package installation

  1. I've ssh'd into publictest6 and am armed with my ticket and instructions. Excellent.
  2. Shoot. I can't yum install the zikula packages because the package needs the more recent versions of a bunch of php modules.  but after reading that mailing list thread I'm still not sure what to do about it. HALP.
  3. Ask Ricky on IRC. Answer: the package doesn't actually need the recent versions of those php modules; the old ones are fine. The package is being updated to reflect that, but in the meantime I can use yumdownloader to grab the rpm and then install it with --nodeps to force past the issue.
  4. This does indeed work. I rejoice, then ask Ricky where I could have found that out for myself - where did the packager give the ok to blithely ignore dependency errors? Answer: buried in mailing list archives - and I know it's impossible for me to keep up with all mailing lists - so asking around was actually the best strategy for me here.
  5. Now that I've installed the zikula package, I easily yum install the zikula-module-crpTag package, and then... well hey, that's interesting. When I try to do the same for the zikua-module-News package, I get an error saying "No package zikula-module-News available." Running a yum search zikula-module confirms that... huh, yeah, it isn't. That's strange, because I know publictest6 is running RHEL 5.3 (because Ricky told me), and when I search for packages (I found that page by googling "search fedora packages") I readily find the entry for zikula-module-News and that it's packaged for EPEL 5, which... should make it available to a machine running RHEL 5.whatever. HALP.
  6. Ask Ricky on IRC. His answer: "I imagine it's waiting on the next EPEL push. We do have epel and epel-testing enabled on our machines, so once it even gets into testing, it should show up there." These two sentences teach me a couple things: (1) packages are pushed to 'available' status for various repositories (in this case, the EPEL repo(sitory)) in regular cycles; they're not necessarily instantaneously available when they're made. Hm. Now I wonder how those cycles happen, how often, and who pushes them. (2) Fedora Infra enables epel and epel-testing on their machines, so if I want to know what packages I can easily install on Fedora publictest machines, those are the two repos I should check. (I already knew that you could specify what repos your computer would be able to install packages from.) (3) It seems unusual for a live server to have a testing repo enabled (but not so weird for a publictest machine).
  7. However, this doesn't tell me what I can do to fix the issue. "Am I out of luck on the News module until the next push?" I ask. "And when would that be?" Ricky outlines 2 options: (1) get it in the Fedora Infrastructure repo (hey, another repo I didn't previously know about that is also enabled on the publictest machines!) (2) install the RPM directly on the machine. When I ask Ricky which one he would pick, he says he would download the RPM from koji and then install it (option 2).
  8. ...so I wander to koji and find the zikula-module-News package there, then wget the noarch rpm into publictest6 and install it (sudo rpm -i --nodeps zikula-module-News-2.4.1-3.el5.noarch.rpm) All modules are now installed. The process so far has taken me about an hour (granted, I've been interrupted by cousins to serve as a piano accompaniment for part of that). In comparison, when I was going through the same process on my own laptop, I'd finished these steps (without needing to ask any questions) by the end of the second minute, most of which was "sit and twiddle thumbs while stuff downloads" time.

Part 2: System setup

<mchua> ricky: [mchua@publictest6 ~]$ sudo chkconfig httpd on
<mchua> sudo: chkconfig: command not found
<mchua>  (but the 'Web Server' and 'MySQL Database' groups are already installed on publictest6).
<mchua> ricky: what's happening / what to do?
<mchua> (I told you I'd need hand-holding through this first round.)
<tmz> mchua: you likely just need to specify the full path to chkconfig, as your user may not have /sbin in the path.
<tmz> e.g.: sudo /sbin/chkconfig httpd on
<mchua> tmz: ...that would do it. thanks!

Yeah, that would be from the "d'oh, I should have checked that" department. This section went without a hitch thereafter.

Part 3: Set up database

  1. I gleefully followed the instructions to set the mysql root password (mysqladmin -u root password the-new-password-I-wanted-went-here)
  2. ...then realized that the mediawiki instance that fedora QA was running on publictest6 might also want to know the mysql root password I'd just changed. Ran to IRC and asked Ricky how they usually worked out accounts/passwords/access between multiple things using mysql on the same server. Answer: "Oh, we usually just leave it blank since it's only accessible if you have a shell there anyway. If you want to change it, I'd store it in a file like /root/mysql_password and make sure anybody sharing that machine knows about it."
  3. That would overcomplicate things, though, so I hurriedly set the mysql root password back to blank. (mysqladmin -u root -p password '' # I guessed that empty '' quotes would give me a blank password, and I was right.)
  4. As a side note: while that was going on, I asked Ricky whether that was a general thing to do for mysql root, becaues it seemed odd to leave root passwords blank. Ricky explained that production machines had /var/lib/mysql chmodded to 700 so that one would need to mysql -u root as root (or as the mysql user) to get access.

Things went without a hitch thereafter.

Part 4: Zikula installation

Around 3:15am, I decided to do the rest of this... tomorrow.