Tag Archives: centos

Release for CentOS-5.9 i386 and x86_64

Posted on by at 6:25 pm

We are pleased to announce the immediate availability of CentOS-5.9 for i386 and x86_64 Architectures.

CentOS-5.9 is based on the upstream release EL 5.9 and includes packages from all variants including Server and Client. All upstream repositories have been combined into one, to make it easier for end users to work with.

via [CentOS-announce] Release for CentOS-5.9 i386 and x86_64.

CentOS is the open sourced version of Red Hat Enterprise Linux.  I run some systems at 5.6 and some at 5.7 and am testing out a 6.2 release.  I tend to avoid updates unless absolutely necessary.  When something works, such as a network service like DNS or Squid or Apache etc. upgrading can cause more problems than they solve — especially when there are no problems to solve.  Being on the latest release isn’t important.  If I were to build out a new system, this release might be something to consider.

SME Server

Posted on by at 4:15 pm

Exceptionally reliable and easy to use, SME Server can be installed and configured in less than 20 minutes – yet it’s powered by a secure and open Linux platform that’s fully upgradeable and customizable. Simply install it on any standard PC and in minutes you’ll have a robust Linux-based LAMP server capable of fully replacing those expensive Windows server licenses and providing a full range of services – including e-mail, firewall, file and print-sharing, web hosting, remote access and more.

via SME Server:About – SME Server.

Oracle Linux: A better alternative to CentOS

Posted on by at 6:45 pm

We firmly believe that Oracle Linux is the best Linux distribution on the market today. It’s reliable, it’s affordable, it’s 100% compatible with your existing applications, and it gives you access to some of the most cutting-edge innovations in Linux like Ksplice and dtrace.

via Oracle Linux: A better alternative to CentOS.

Hmmm.  We’ll see about that.

How is this better than CentOS?

Well, for one, you’re getting the exact same bits our paying enterprise customers are getting. So that means a few things. Importantly, it means virtually no delay between when Red Hat releases a kernel and when Oracle Linux does:

CentOS 64 bit bad ELF interpreter

Posted on by at 6:51 pm

You’re on a 64-bit system, and don’t have 32-bit library support installed.

sudo yum install glibc.i686

via linux – CentOS 64 bit bad ELF interpreter – Stack Overflow.

Also had to yum install gtk2.i686.  Here’s the solution from the above link for  Debian based systems:

Updated: Since it seems this answer is still getting viewed, and occassionally up-voted, note that the solution above works on CentOS, Fedora, or Red Hat derived operating systems; on a Debian or Ubuntu derived system, however, one would instead use

 sudo apt-get install ia32-lib

For some reason, after all these years of using 64 bit OSs, and still having an active, running FC10 installation, this was the first time I had no choice but to run a 32-bit app on a 64 bit machine.
The above solution worked

Red Hat / CentOS: Swap / Change Ethernet Aliases

Posted on by at 12:33 am

Red Hat / CentOS: Swap / Change Ethernet Aliases.

This didn’t work the first time I tried it and now it does.  For some reason eth0 and eth1 get switched on the 64bit CentOS 5.7 build which causes routing problems.  This can also be solved by fixing the static routes in /etc/rc.local.  It bothered me to have these interfaces have different names depending on what OS is running.  I think there’s also a way to force this in /etc/udev/ directory by adding a persistent-net rule file.  It all works now.

BTW: I also changed /etc/sysconfig/hwconf but don’t think that had any effect.

Upgrade PHP 5.1/5.2 to 5.3 on CentOS

Posted on by at 11:22 pm

I’m finding that more and more software developers are being quite inconsiderate and are making code that requires PHP 5.3. Since many server-based and long-term support distros are still on PHP 5.2, this can make things difficult quickly.

via Upgrade PHP 5.1/5.2 to 5.3 on CentOS :: Chris Jean.

Here here!  I needed to do the following on CentOS 5.7:

#sudo yum erase php

#sudo yum erase php-commons

#sudo yum install php53

#sudo yum install php53-mysql

AdditionalResources/Repositories/RPMForge

Posted on by at 9:37 pm

The default RPMforge repository does not replace any CentOS base packages. In the past it used to, but those packages are now in a separate repository (rpmforge-extras) which is disabled by default.

You can find a complete listing of the RPMforge package packages at http://packages.sw.be/

via AdditionalResources/Repositories/RPMForge – CentOS Wiki.

The rpm at this link allows for yum to see the additional packages — such as alpine and perhaps others that were missing in the base.

The Mystery of Duqu: Part Six (The Command and Control servers)

Posted on by at 11:40 pm

The Mystery of Duqu: Part Six (The Command and Control servers) – Securelist.

For our particular server, several spikes immediately raise suspicions: 15 February and 19 July, when new versions of OpenSSH were installed; 20 October, when the server cleanup took place. Additionally, we found spikes on 10 February and 3 April, when certain events took place. We were able to identify “dovecot” crashes on these dates, although we can’t be sure they were caused by the attackers (“dovecot” remote exploit?) or simply instabilities.

Of course, for server ‘A’, three big questions remain:

  • How did the attackers get access to this computer in the first place?
  • What exactly was its purpose and how was it (ab-)used?
  • Why did the attackers replace the stock OpenSSH 4.3 with version 5.8?

Interesting read. Apparently there might have been a zero day exploit in openssh.

From: http://en.wikipedia.org/wiki/Duqu

Duqu is a computer worm discovered on 1 September 2011, thought to be related to the Stuxnet worm. The Laboratory of Cryptography and System Security (CrySyS)[1] of the Budapest University of Technology and Economics in Hungary, which discovered the threat, analyzed the malware and wrote a 60-page report[2], naming the threat Duqu.[3] Duqu got its name from the prefix “~DQ” it gives to the names of files it creates.

Here‘s an interesting comment on slashdot.

The only things you should need open to the internet are SSH (“the attackers may have used a zero-day in OpenSSH 4.3 to compromise the C&C servers initially”) and/or IPSec/L2TP. Anything else should redirect to a DMZ that does NOT route to the same subnet as SSH/IPSec/L2TP. The DMZ should not have port access to the regular network (everything should be pushed). The firewall should be set to not allow active connections out from the DMZ to anywhere, and any activity should not just be logged, but flagged and sent to the administrator. All devices in the DMZ should log to a remote (to them) syslog that is polled from outside the DMZ.

There… that’s the ideal world. In reality, this doesn’t account for people who don’t have that much hardware/expertise with VMs, for people who don’t keep up with their patches, for those who want to do an end-run around this policy to set up torrents, etc. directly from their working computer, etc.

It also doesn’t help that most gateway routers these days have some full-fledged OS inside and as a result often have exploits that can be leveraged directly against them due to inappropriate default configurations.