virsh (un)define

kvm virsh tool has nice features to define and undefine particular virtual machine.If we have .xml kvm machine file then using
#virsh define kvmmachine.xml
will define it and machine will be ready for use.If you,as I do very often,need to deploy same virtual machine name ( eg: new / full clone of cluster node ) then cloning machine will not allow you to use same name as it is internally remembered by kvm.Reboot of host will fix this,but that is not solution ;), for such cases,
#virsh undefine kvmmachine
will undefine machine ( remove its name from kvm namespace ) and you can clone it again.Notice that when # virsh undefine kvmmachine is used we use virtual machine name as (was) visible in #virsh list output

#kvm-virsh-virtualization-define-undefine

omxplayer

If you have Raspberry PI and decide to use it media center,you will probably look for Raspberry PI ready player.

omxplayer is tool for you

#aptitude install omxplayer xterm

to start using it, right click on desired video->open with->and enter below for custom command

xterm -fullscreen -fg black -bg black -e omxplayer -o hdmi -r %f

to get it running in full screen mode.

#linux, #omxplayer, #raspberry-pi

iptables-persistent

With Red Hat based distributions ( Centos, Sciencific Linux, Oracle Linux, Fedora 😉 ) adding new iptalbes rules is as easy as editing /etc/sysconfig/iptables or running iptables-save after adding new rules – iptables-save will automatically edit /etc/sysconfig/iptables and add new rules there.

For Debian,there is also an easy way to ensure iptables rules to start on boot – use iptables-persistent package which is an boot-time loader for iptables rules.

#aptitude install iptables-peristent

After installation we can find files which are part of iptables-persistent

#dpkg -S iptables-persistent
iptables-persistent: /usr/share/doc/iptables-persistent/README
iptables-persistent: /usr/share/doc/iptables-persistent
iptables-persistent: /etc/init.d/iptables-persistent
iptables-persistent: /usr/share/doc/iptables-persistent/changelog.gz
iptables-persistent: /usr/share/doc/iptables-persistent/copyright

for us is interesting /etc/init.d/iptables-persistent script,from where we see

load_rules()
{
        log_action_begin_msg "Loading iptables rules"

        #load IPv4 rules
        if [ ! -f /etc/iptables/rules.v4 ]; then
                log_action_cont_msg " skipping IPv4 (no rules to load)"
        else
                log_action_cont_msg " IPv4"
                iptables-restore  /dev/null
                if [ $? -ne 0 ]; then
                        rc=1
                fi
        fi

        #load IPv6 rules        
        if [ ! -f /etc/iptables/rules.v6 ]; then
                log_action_cont_msg " skipping IPv6 (no rules to load)"
        else
                log_action_cont_msg " IPv6"
                ip6tables-restore  /dev/null
                if [ $? -ne 0 ]; then
                        rc=1
                fi
        fi

        log_action_end_msg $rc
}

if you have ipv4 rules,then they will be saved in /etc/iptables/rules.v4, in case of ipv6 rules, they will go to /etc/iptables/rules.v6

Rough steps may be, create iptables script file,test….test it,execute it, save rules with iptables-save > /etc/iptables/rules.v4,and that is.iptables-save will send them to /etc/iptables/rules.v4 ( for ipv6, you will need to use ip6tables commands in order to update /etc/iptables/rules.v6 file ) – next time machine boots, iptables-persistent will read and apply them from there.

#debian-iptables-iptables-persistent-security

unalligned pointer debian bug …

Fedora 17 host + ( kvm ) debian 6 guest … ends as showed below.Seems nice homework :). Anybody out there has already solution? Thanks

#debian-kvm

Happy b-day Debian :) … long live

The Debian Administration Handbook released

The Debian Administration Handbook is online available.
More details debian-handbook.info — Debian Handbook official web page.

Debian is great linux distribution,and releasing The Debian Administration Handbook will help to make it even better.

Book is possible to get for free ( pdf, mobi, epub formats ),but if your financial situation allows,I fully recommend to buy hard copy and help Debian project

Thanks to Raphaël Hertzog for work on it

Enjoy The Debian Administration Handbook 🙂

#debian-administration-handbook

Fight against ISP rules

When I am on road I am forced to use internet connection at homes of my friends / family,but that is very often an interesting experience.

The thing I do not understand when it comes to ISP business is rule to lock MAC address of 1 ( one ) machine and do not allow to connect another machine to network ( yes,they allow that but you will need to call them to change MAC address at their side )

To all WW ISPs: What is issue to allow to connect another laptop to internet and why is so important to lock computer’s MAC?

I want to use my laptop to browse internet,and it is funny to see that only one machine is “internet-able”.

Changing MAC address is super easy task,put below in some script eg, changemac.sh

#!/bin/bash
ifconfig eth0 down
ifconfig eth0 hw ether 00:11:D8:D3:26:FE
ifconfig eth0 up

copy script to /etc/init.d/ and execute

# update-rc.d -n changemac.sh defaults

Above MAC address is one in my case,replace it with MAC address of machine which is “internet-able” in your case 😉

Above applies for Debian and problem is “solved”.Next time you boot machine with connected cable it will be automatically connected,ISP will think that there is not change,they only care about MAC – at least ones I had to deal with.Above script can be executed manually too.

But still I do not see purpose of this ISP practice,ISP guys changing MAC address never was an “rocket science”

#mac-isp

Keep same package versions on machines

Updating system(s) is day-to-day duty of all of us who have to play with system administration.With update process there is not anything bad and that is necessity to have all under control ( hopefully ).

All OS-es have their own package management system which makes life easier.Recently was asked question

I have many critical machines which must contain all packages at same level,but first I would like to install all packages on my “test environment” and if everything is fine,I will move updates to production boxes,how I can do that?

At first I did not understand question fully,and I recommended to update machines agains distro repositories,but I was corrected that that approach will not work.The aim is to run updates in test environment first and move them once it is confirmed that all is fine,and problem are so-called “delta updates”

What are “delta-updates”?If packed A is updated today and we install it on test machine,testing process will take some time before we move these packets to production.Here is problem that during time we test updates on our test system that new updated version of packet “A” is released.If we run update against distro repository we will get this new packed installed directly on production system — thus jumping verification phase on our test system ( I know that there is QA process and all packets are tested before released — but not for specific case for specific application )

For Red Hat based distros as one of possible solution for this problem can be solution as below

# rpm -qa | sort > all_packets.txt

above will list all packets and their versions installed on test machine.

If you scp above file to production machine and run

# yum install $(cat all_packets.txt)

yum will run install operation against every line from all_packets.txt

If packet version in all_packets_txt is same as one installed yum will report that packet is installed and already at latest available version.The ones which were updated will be updated to same version as on test system.

Debian / Ubuntu case:

# dpkg –get-selections | awk ‘{ print $1 }’ > sort > installed.txt

and install packages on second machine

# aptitude install $(cat installed.txt)

Obviously this process is not handy one ( some will say the most optimized ) but when you would like to avoid “delta-updates” and be sure that your application which is planned to run with specific (sub)version will get package versions for which you are sure they are fine and avoid surprises,then can be used.

@all: hints how to do same on some other distributions are welcome.Thanks

#installation-updates-rpm-dpkg

(none) as hostname is bad to have …

I am not sure how Debian team will treat bug 650822 but I found it annoying.

If you by accident hit tab and leave an space in hostname line on Debian ( and Ubuntu ) in /etc/hostname,then after next reboot hostname will be set to (none).

I proposed potential patch/workaround for it,edit /etc/init.d/hostname.conf and in do_start() function change line

[ -f /etc/hostname ] && HOSTNAME=”$(cat /etc/hostname)”

to

[ -f /etc/hostname ] && HOSTNAME=”$(cat /etc/hostname | sed ‘s/^[ \t]*//;s/[ \t]*$//’)”

which will lead that space in /etc/hostname is ignored if present at end of line and set up correct hostname

#debian-2

;)

Long time ago I “discovered” moo 😉

# root@debdns:/etc/init.d# apt-get moo
(__)
(oo)
/——\/
/ | ||
* /\—/\
~~ ~~
….”Have you mooed today?”…

🙂

#fun-2