Switched On Tech Design

Category: CentOS

  • How to protect your CentOS server from the Shellshock exploit

    Shellshock is quite a serious security hole found a couple of days ago in Bash; to check whether your CentOS server is vulnerable run the following in a terminal:

    env VAR='() { :;}; echo Shellshock vulnerable!' bash -c "echo Bash Testing"

    If your system is vulnerable, you will see:

    Shellshock vulnerable!

    Bash testing

    If it is not vulnerable, you will see:

    bash: warning: VAR: ignoring function definition attempt
    bash: error importing function definition for `VAR’
    Bash testing

    If you are vulnerable, you can update bash by running the following:

    sudo yum update bash

    Once the update has finished, run the code to check your vulnerability again and it should be sorted.

  • How to cache yum repositories on CentOS using apt-cacher-ng on Debian or Ubuntu

     

    If you have a lot of virtual (or real) machines running Debian or Ubuntu and a limited internet connection, it can make a lot of sense to use apt-cacher-ng to create a local cache of the packages you use so that they are only downloaded once. The current version of apt-cacher-ng can also help out with yum repositories!

     

    On CentOS, edit /etc/yum.conf and add:

     

    proxy=http://[ip-of-your-local-apt-cacher-ng-server]:3142

     

    If you have changed the default port of apt-cacher-ng from 3142, you will need to modify that. Our example file:

     

    [main]
    cachedir=/var/cache/yum/$basearch/$releasever
    keepcache=0
    debuglevel=2
    logfile=/var/log/yum.log
    exactarch=1
    obsoletes=1
    gpgcheck=1
    plugins=1
    installonly_limit=5
    bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum
    distroverpkg=centos-release
    proxy=http://10.1.1.12:3142

    #  This is the default, if you make this bigger yum won’t see if the metadata
    # is newer on the remote and so you’ll “gain” the bandwidth of not having to
    # download the new metadata and “pay” for it by yum not having correct
    # information.
    #  It is esp. important, to have correct metadata, for distributions like
    # Fedora which don’t keep old packages around. If you don’t like this checking
    # interupting your command line usage, it’s much better to have something
    # manually check the metadata once an hour (yum-updatesd will do this).
    # metadata_expire=90m

    # PUT YOUR REPOS HERE OR IN separate files named file.repo
    # in /etc/yum.repos.d

     

    As you can see, our local apt-cacher-ng VM is 10.1.1.12.

     

    Run yum update and check your apt-cacher-ng’s cache – you should now see some CentOS respositories cached there.

  • Rsync error when connecting to CentOS: rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

     

    We helped rebuild a backup VM which receives data over rsync today; the first rsync attempt failed with the vague error message:

     

    rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

     

    The problem ended up being that the rsync package was not installed. A simple:

     

    yum install rsync -y

     

    …fixed the problem and shortly the backups were back to normal.

  • New CentOS WordPress install: Error 500

     

    Was asked to troubleshoot a client’s installation technique for WordPress on CentOS 6.x yesterday; they were receiving an Error 500 when they tried to access index.php for the first time. Checking the Apache logs showed:

     

    SoftException in Application.cpp:431: Mismatch between target GID (522) and GID (65531) of file “/home/andrea/public_html/index.php”

    Premature end of script headers: index.php

     

    What was happening was that the client was un-tarballing the latest.tar.gz file as root and then changing the ownership of the file with the following:

     

    chown -R [user] *

     

    Changing that command to:

     

    chown -R [user]:[usergroup] *

     

    e.g. here:

     

    chown -R andrea:andrea *

     

    fixed that error. By not specifying the new group there was an ownership mismatch where the system expected one group but got another. There are many  causes for an Error 500 – it’s a good habit to check the Apache logs first for pointers as to where to start troubleshooting.

  • top 10 hong kong dating site

     

    Rather than being in /var/log as you might expect, the Apache logs can be found at:

     

    /etc/httpd/logs

     

    Here you’ll find the usual access, error etc. logs.

  • bloom matchmaking

     

    If you’re using a virtual server (whether online or your own physical machine) it can be handy sometimes to check how many CPU cores are available; here are two easy methods of doing this. The first:

     

    nproc

     

    This will return a single number, whether it be 1, 2, 4 or otherwise. For a more detailed look, try:

     

    lscpu

     

    This will usually give a more complex readout, e.g.:

     

    root@server [/]# lscpu
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                1
    On-line CPU(s) list:   0
    Thread(s) per core:    1
    Core(s) per socket:    1
    CPU socket(s):         1
    NUMA node(s):          1
    Vendor ID:             GenuineIntel
    CPU family:            6
    Model:                 45
    Stepping:              7
    CPU MHz:               2000.024
    BogoMIPS:              4000.04
    Hypervisor vendor:     Xen
    Virtualization type:   para
    L1d cache:             32K
    L1i cache:             32K
    L2 cache:              256K
    L3 cache:              15360K
    NUMA node0 CPU(s):     0

     

  • Finding /var/log/auth.log in CentOS 6

     

    This one is straight-forward – if you’re used to Debian and are in a CentOS system looking for /var/log/auth.log you’ll find it in:

     

    /var/log/secure

     

    Short and sweet!