Well, after some searching today (we applied the VMware Update 2 today, thus the VMware Tools update too), I finally found out what is causing that problem. Though the problem seems to be not limited to virtual systems alone, I just browsed through this Novell Forum thread which pretty much describes my problem. I found the same error in the VM’s I tried to mount a CD image. ...
Well, I’ve been having issues with our SMT. Basically after the release of SLES11 SP2 in February, I’ve been waiting for the repositories to turn “mirrorable”, which they haven’t yet. So I wrote a mail to the EMEA customer support. And yesterday I got a reply, stating that my mirror credentials had been regenerated. And guess what ? I can mirror stuff again. So if you ever have any issues like the ones I described (or any of the people in the forum threads experienced), write a mail to your Novell customer support. 😛
I spent some time yesterday figuring out ways on how to assign custom (as in self-built) RPMs to a installation using SMT. First you obviously need a " external" repository, that can be integrated into the SMT. So we need to create repository someplace, where the SMT can go and grab it. I ain’t gonna cover the sharing part, since that is your job! I’m just gonna cover the steps on how to create the custom repository and how to integrate it into the SMT. ...
Well, it’s 7pm. I’m sitting at home and thinking about why in gods name rug isn’t adding my update repository. I can add the service using yast inst_source, but when yast then syncs with ZenWorks, it tells me something like: Failed to get repomd/repodata.xml; Reason: 530 - Access denied So my fellow co-worker turned on the debug-logging and we quickly found out why: rug isn’t using the command line credentials I was passing. ...
OK, so today was the highlight of the week … We updated apache2 on Tuesday (yeah, that’s still 2.0.49, so if you have some exploits - try them 😛 ) and now out of the sudden we have major performance issues. We looked nearly the whole forenoon for a reason, why the frackin’ apache was using 236% of the CPU’s. In the afternoon, when my co-worker decided to go home (that was ~1500), I decided to revert back to the old patch level. But that isn’t as easy as you think (at least on SLES). The only thing I wanted to do, was something like this: ...
Once again, I’m compelled to play (other call it administering 😛) with our TYPO3 cluster (which is sadly running SLES). One thing I just learned about SLES (for the ones curious, its Novell’s SuSE Linux Enterprise Server and yes, it suffers the same pain as SuSE/openSuSE). They split one single config file (at least the apache2 one) into 9 (or more) different files. Another thing is, for what the hell does a simple LAMP need a full blown Xorg w/ KDE installed ? ...