Menu

Здравейте и добре дошли в #root.bg!

Тук може да намерите статии и уроци за linux, мрежи и тяхната защита, игри и забавление, както и хобита – ролери, дронове и много други.

Ако искате да помогнете за развитието на root.bg

моля направете го от бутона тук!
Почерпи ме!

 

Алтернативен начин за мигриране на OpenVZ към LXC

, , 0

Алтернативен начин за мигриране на OpenVZ към LXCПривет,

В продължение на постовете ми : Чао OpenVZ, Здравей LXC и Convert OpenVZ to LXC искам да споделя за проблем който ме мъчеше от тогава до сега.

 

Става дума за последната ми OpenVZ останала виртуална машина, която ми създаваше ядове при миграцията към LXC. Проблемите бяха от това (поне аз така мисля), че самата виртуална машина беше доста голяма от към дисково пространство. Поради този факт, стандартния начин за мигриране описан тук не функционираше както трябва.

Всичките стъпки минаха до момента с restore-ването. Root дяла на виртуалната машина не се получаваше както при всички останали – а именно един файл с разширение .raw. Тук всичко се разархивираше както при OpenVZ и simfs. Поради тачи причина и новата мигрирана LXC машина не тръгваше – даваше грешка за липсващ rootfs.

Днес обаче оправих този проблем – малко нестандартно но пък успешно! 🙂

Инсталирах си LXC контейнер със същата операционна система като тази на OpenVZ машината. Пуснах я и се логнах в нея през SSH и инсталирах rsync и screen.

След това през нея чрез screen закачих процес, чрез който се свързах към OpenVZ хост-а, и си смъкнах цялото съдържание на OpenVZ виртуалната машина. Това става благодарение на факта, че е именно simfs.

Ето и моят алтернативен начин за мигриране на OpenVZ към LXC :

rsync -vaz --delete -e 'ssh -p 22' root@192.168.168.9:/var/lib/vz/private/105/ / --exclude '/proc/*' --exclude '/dev/*' --exclude '/sys/*' --exclude '/tmp/*'

След като приключи процеса, спрях OpenVZ хоста (192.168.168.9) , копирах му мак адреса и другите мрежови настройки на новата LXC машина и я рестартирах.

Крайния резултат беше следния – старата ми виртуална машина вече беше LXC, и си работеше даже още по-добре от преди!

Така вече мога да кажа със задоволство, че успешно и напълно мигрирах към LXC.

Чао OpenVZ , благодаря ти за всичко!

Чао VMware ESXi, Здравей Proxmox cluster

, , , , 0

vmware esxi logoПривет,

От 2012та година насам имам един Intel сървър с VMware ESXi 4.1. От много време насам мисля как най-лесно и безболезнено мога да мигрирам виртуалните машини от него към Proxmox и да го преинсталирам с последната версия на Proxmox 4.2.

Оказа се, че конвертирането от VMware (vmdk) към Proxmox (qcow2 или raw) не е кой знае колко сложно. Общо взето се използва командата qemu-img convert.

Ето и пример :

qemu-img convert alpha_4-flat.vmdk -O qcow2 alpha.qcow2

или повече инфо тук.

Принципът е следния :

  1. Логваме се през SSH към VMware сървъра и влизаме в datastore папката където се съхраняват нашите виртуални машини.
  2. Намираме виртуалната ни машина, чиито файл трябва да завършва на -flat.vmdk : alpha_4-flat.vmdk.
  3. Прехвърляме файла на proxmox сървъра и конвертираме.
  4. Създаваме нова виртуална машина през proxmox уеб интерфейса със същите параметри като старата.
  5. През SSH на proxmox сървъра влизаме в директория /var/lib/vz/images/100/ (100 е ID-то на виртуалната ни машина) и заместваме съществуващия файл с нашия конвертиран такъв.
  6. Стартираме новата ни виртуална машина и всичко трябва да е наред!
Още..

MyISAM migrate to InnoDB

, , , , 0

MyISAM migrate to InnoDB using mysqldump

Привет,

В MySQL има много начини да се мигрира една таблица от MyISAM към InnoDB.

В този пост ще споделя, как се прави това чрез mysqldump.  Този тип миграция се нарича offline, тъй като има downtime. Разбира се, ако имаме повече от един MySQL сървър, този downtime може да бъде избегнат. А като цяло, главната идята на тази схема, е rebuild-ване на индексите на таблицата(те) – тоест оптимизирането им.

Стъпките са следните :

  1. Бекъп на структурата на таблиците в базата.
  2. Бекъп на данните на самата база.
  3. Конвертиране на бекъпа със структурата от MyISAM към InnoDB.
  4. Изтриване и създаване на базата, и наливане на данните й на ново (постигайки така желаната оптимизация)

Стъпка едно:

Базата ни се казва crm – правим й два бекъпа – на структурата и на данните :

mysqldump -uroot -p --no-data -R --triggers crm > crm_schema.sql

и на данните :

mysqldump -uroot -p --no-create-info -R --triggers crm > crm_data.sql

Следва конвертирането към InnoDB:

sed -i.bak 's#MyISAM#InnoDB#g' crm_schema.sql

 

И последната стъпка : създаване на база на ново и наливане на информацията от двата бекъпа :

mysql -uroot -p -e "create database crm"
mysql -uroot -p crm < crm_schema.sql
mysql -uroot -p crm < crm_data.sql

 

Това е!

PS. Намерих много полезен линк за MySQL репликация без downtime.  10х BRYAN KENNEDY

How To Log Your Bash History With Syslog

, , , , 0

How To Log Your Bash History With SyslogПривет,

В този пост ще пиша, как бързо и лесно можем да логваме bash history-то на всички потребители в linux машина със syslog.

За целта трябва да добавим следното в /etc/bash.bashrc :

function log2syslog
{
declare COMMAND
COMMAND=$(fc -ln -0)
logger -p local1.notice -t bash -i -- "${USER}:${COMMAND}"
}
trap log2syslog DEBUG

Излизаме и влизаме през SSH и резултата е на лице :

tail -f /var/log/syslog
Aug 5 11:44:05 Server bash[12765]: root:#011 w
Aug 5 11:44:08 Server bash[12790]: root:#011 cd /etc/mysql/
Aug 5 11:44:08 Server bash[12792]: root:#011 ls
Aug 5 11:44:11 Server bash[12825]: root:#011 ls -lah
Aug 5 11:44:14 Server bash[12860]: root:#011 cat my.cnf

Това е!

Load More