Hello and welcome to #root.bg!
Here you can find tutorials about linux, networks and their firewall, games and fun, as well as hobbies – rollers, drones and many more.
Here you can find tutorials about linux, networks and their firewall, games and fun, as well as hobbies – rollers, drones and many more.
Николай Николов Работа, Howto lxc, openvz, proxmox 0
Привет,
В продължение на поста ми Чао OpenVZ, Здравей LXC , днес ще пиша как точно направих конвертирането от OpenVZ към LXC.
Първото което трябва да спомена е, че бях събрал всички OpenVZ виртуалки от сървърите в един CentOS 6 с vzkernel ( тук целта ми беше миграцията на Proxmox-a към 4, и OpenVZ-тата бяха оставени на заден план).
Та.. на CentOS-а ми трябваше vzdump , обаче по подразбиране тази команда я няма. Добавих следното репо:
[soluslabs] name=Soluslab Repo #baseurl=http://repo.soluslabs.com/centos/$releasever/os/$basearch mirrorlist=http://repo.soluslabs.com/centos/mirrors-soluslabs gpgcheck=0 enabled=1
във файла : /etc/yum.repos.d/solusvm.repo и инсталирах vzdump чрез :
yum install vzdump
После последва самия бекъп на виртуалката:
[root@Alien ~]# vzdump 138 INFO: Starting new backup job - vzdump 138 INFO: Starting Backup of VM 138 (openvz) INFO: status = CTID 138 exist unmounted down INFO: creating archive '/vz/dump/vzdump-138.dat' (/var/lib/vz/private/138) INFO: Total bytes written: 34812764160 (33GiB, 9.6MiB/s) INFO: file size 32.42GB INFO: Finished Backup of VM 138 (00:58:33) [root@Alien ~]#
И накрая го преместих от /var/dump/vzdump-138.tar в proxmox сървъра и стартирах процеса на мигриране от OpenVZ към LXC (Convert OpenVZ to LXC) :
sun:~# pct restore 138 vzdump-138.tar -storage nas-nfs Formatting '/mnt/pve/nas-nfs/images/138/vm-138-disk-1.raw', fmt=raw size=85899345920 mke2fs 1.42.12 (29-Aug-2014) Creating filesystem with 20971520 4k blocks and 5242880 inodes Filesystem UUID: 06aa1619-d508-421d-a966-e32eeac47442 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Multiple mount protection is enabled with update interval 5 seconds. Writing superblocks and filesystem accounting information: done extracting archive '/root/vzdump-138.tar' Total bytes read: 34812764160 (33GiB, 69MiB/s) Detected container architecture: amd64 ########################################################### Converting OpenVZ configuration to LXC. Please check the configuration and reconfigure the network. ###########################################################
Тук е важно да отбележа, че избрах за storage nas-nfs (това е монтирания по nfs nas сървър). Списък с монтираните storage дялове може да се види така :
sun:~# pvesm status local dir 1 15321089528 1724523996 13596565532 11.76% mysql-ssd-sun dir 1 114723368 61060 108811584 0.56% nas-nfs nfs 1 29098686272 17879096416 11219589856 61.94%
И не на последно място, е нужно да се добави мрежов интерфейс на ново от proxmox уеб интерфейса, със съответните IP адреси и тн..
Ами това е… след като го пуснах всичко си беше 6 точки! 🙂
Същата процедура направих и с останалите 10 OpenVZ виртуалки.
Николай Николов Работа docker, lxc, openvz, proxmox 0
Привет,
В мои стари постове от 19.08.2013 и 04.02.2016 започнах да споменавам LXC в блога. LXC е нова контейнер технология базирана на docker. LXC може да се инсталира на всеки линукс с kernel версия 3.8 и по-голяма.
Искам да споделя, че вече мигрирах всички мои стари OpenVZ виртуални сървъри към LXC. Главната причина за това беше, че мигрирах самите node сървъри ( в моят случай proxmox 3 до proxmox 4.2 ). Това само по себе си доведе и до използването на LXC като контейнер среда (защото при версия 4 ).
Предимствата които получих след миграцията на proxmox до 4.2 са : нов работещ HA cluster (3 node сървъра + общ дисков масив), използване на kernel 4.4.x с всички нови драйвери и библиотеки и много други. Няма да изпадам в подробности как се прави този HA cluster – всичко е описано тук.
Като цяло, за около 2 месеца използване на production среда, не съм видял абсолютно никакви проблеми с LXC.
Използвам готовите темплейти от сайта на OpenVZ и всичко си върви отлично.
Вече бих казал, че препоръчвам използването на LXC, особенно след като станах и голям фен на docker =)
Николай Николов Howto dev, repository, wordpress 0
Привет,
На работата, колегите програмисти използват dev сървъри за тестове на wordpress плъгини, темплейти и локални repository-та, чрез които ги обновяват.
С течение на времето, се сблъскахме с много странен проблем – при опит за обновяване на plugin/theme даваше следната грешка : WordPress: Download failed. A valid URL was not provided.
Downloading install package from http://dev-server.root.bg/path/download… Download failed. A valid URL was not provided.
Оказа се, че в wordpress след версия 3.6 има заложена защита спрямо локалните мрежи, и всичко от рода на 192.168.0.0/16 , 10.0.0.0/16 , 127.0.0.1 или 172.16.0.0/16 бива отрязано от самия WP.
Проблема се оправя, като се добавят следните редове най-долу във wp-config.php :
add_filter( 'http_request_host_is_external', 'allow_my_custom_host', 10, 3 ); function allow_my_custom_host( $allow, $host, $url ) { if ( $host == 'dev-server.root.bg' ) $allow = true; return $allow; }
Забележка : задължително тези редове трябва да са след :
/** Absolute path to the WordPress directory. */ if ( !defined('ABSPATH') ) define('ABSPATH', dirname(__FILE__) . '/');
Това е! =)
Благодаря на Emanuele Tessore за линк-а.
Николай Николов Howto innodb, mysql, mysqldump 0
Привет,
Днес ми се наложи да възтановявам счупени бази (главно с InnoDB таблици) , като за целта имах общ бекъп, голям около 6GB. Една от базите ми беше много голяма, а останалите малки – проблема беше обаче точно с тях. За целта ми трябваше нещо което да направи: MySQL split dump to different databases , или да ми раздели този голям общ бекъп на отделни файлове за всяка една от базите, за да мога да си ги възтановя една по една.
За целта се разрових из нета и попаднах на няколко решения, като в този пост ще споделя за 2 от тях. Едното изкарва бекъп само за определна база, а второто за всички наведнъж.
Ето и първият вариянт :
sed -n '/^-- Current Database: `c20elenhen`/,/^-- Current Database: `/p' 20160628025005-db-all.sql > c20elenhen.sql
Накратко – желаната от мен база, която изках да изкарам от бекъпа се казва: c20elenhen , бекъп-а ми се казва : 20160628025005-db-all.sql , а файла в който искам да запиша всичко се казва: c20elenhen.sql – бързо и лесно! 🙂
Вторият вариянт обаче повече ми харесва, чащото директно ми раздели всички бази по отделно, без да трябва да описвам всяка след всяка. Ето и perl скрипт-а:
#!/usr/bin/perl -w # # splitmysqldump - split mysqldump file into per-database dump files. use strict; use warnings; my $dbfile; my $dbname = q{}; my $header = q{}; while (<>) { # Beginning of a new database section: # close currently open file and start a new one if (m/-- Current Database\: \`([-\w]+)\`/) { if (defined $dbfile && tell $dbfile != -1) { close $dbfile or die "Could not close file!" } $dbname = $1; open $dbfile, ">>", "$1_dump.sql" or die "Could not create file!"; print $dbfile $header; print "Writing file $1_dump.sql ...\n"; } if (defined $dbfile && tell $dbfile != -1) { print $dbfile $_; } # Catch dump file header in the beginning # to be printed to each separate dump file. if (! $dbname) { $header .= $_; } } close $dbfile or die "Could not close file!"
А схемата става по следният начин :
mac-mini: nikolay$ perl splitmysqldump.pl < 20160628025005-db-all.sql Writing file c15mobileroundcube_dump.sql ... Writing file c15roundcube_dump.sql ... Writing file c1aps1_dump.sql ... Writing file c1aps2_dump.sql ... Writing file c1aps4_dump.sql ... Writing file c1hdbox_dump.sql ... Writing file c1luxbeton_dump.sql ... Writing file c1newhdbox_dump.sql ... Writing file c1newtester_dump.sql ... Writing file c1paste_dump.sql ... ......
Това е общо взето…