Днес реших да направя няколко теста върху чиста Cpanel инсталация за която имах необходимост от няколко потребителя. Тъй като не исках да натоварвам работещите сървъри с пакетиране архивиране и трансфер на файловете използвах архивите от предишната вечер. Трансферирах си всички архиви в /home и установих че Cpanel не предлага възстановяването на повече 1 акаунт едновременно както през GUI така и през CLI. През GUI тъй като нямаше как да се получи номера реших да се изхитря с cli скрипта restorepkg. Използването му е безкрайно просто

/scripts/restorepkg username.tar.gz

Като действието се повтаря за всеки потребител по отделно. При опит да използвам * вместо името на потребителя скрипта деректно ме отряза затова трябва да се подходи малко по елегантно –


archives=$(ls /home/ | grep tar.gz)

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Сега бързо обяснение. Правим си списък с всички архиви и го блъскаме в променливата archives след това обхождаме списъка елемент по елемент като стартираме разпакетирането за всеки архив по отделно. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.

Да приемем следната ситуация правили сте нещо и сте и си смазали MBR записа. И след това въобще нямате или просто получавате съобщение за грешка в GRUB. Възстановяването си е тривиална операция от където и да се погледне

1. Направете си Live CD/DVD/USB каквото имате под ръка с каквото и да било дистро

2. Преминаване в chroot на старта ви OS така ще си запазите настройките и ще използвате версията на grub с която те си били при мен и имам доста неща описани в CMD-то на Grub

mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

3. Вече сме chroot на вашето дистро остана само да се преинсталира груб и да се ъпдейтне (за всеки случай)

grub-install /dev/sda
update-grub

Воала рестартираме и сме готови да работи както преди и всичко е непокътнато ни лук яли ни лук мирисали  😉 Възстановяване на GRUB

От време на време ми се налага да ползва Bitcoin URI и когато ми се наложи клиента ми не се е асоциирал е дразнещо, че трянва да правя всичко на ръка. Продцедурата е изключително тривиална по въпросната асоциация. Може да бъде синтезирана в следните 5 точки

  1. Отворете в адрес бара си about:config
  2. Създайте нов ключ от тип boolean (клис с десен бутон на мишката -> new -> boolean)
  3. Въведете име: network.protocol-handler.expose.bitcoin
  4. Изберете стойност false
  5. Следващият път когато кликнете на Bitcoin URI ще бъдете попитани за избор път до Bitcoin клиента си. Бъдете сигурни че е с изпълними права.

Аз лично използвам MultiBit клиента който е има всичката необходима фунционалност и е достатъчно пъргавичък

Миграцията от RAID1 до RAID5 се оказа многократно по лесна от колкото си мислех 🙄 В общи линии са 5 прости стъпки малко чакане и 1 една бира за кураж.

При мен системата има създаден RAID масив md0 в който участват 2 диска sda и sdb. Ще добавя към тях 3-ти sdc за да създам RAID5 от 3 диска. Като цяло тая акробатика е с научна цел на виртуалка още не съм я тествал в реална среда, но не очаквам драми и на реална машина като му дойде времето.

  1. Създаваме същото оформление файловата система като на другите ни дискове – sfdisk -d /dev/sdb | sfdisk /dev/sdc
  2. Надграждаме настоящият ни масив на RAID5 – mdadm –grow /dev/md0 –level=5
  3. Добавяме новия диск към масива – mdadm –manage /dev/md0 –add /dev/sdc . Тука идва тънкия момент че масива все още продължава да си RAID1 и няма да започне се синхронизира понеже новия диск ни е spare
  4. Най важният момент sdc става активен и започва синхронизацията – mdadm –grow /dev/md0 –raid-devices=3 . Добър момент да си отворите бирата ако не е направено 😉 Не прекъсвайте процеса при никакъв случай!!!
  5. След като приключи синхронизацията остана да преоразмери дяла понеже загубата на пространство при RAID1 e 1/n а при RAID5 e 1-1/n

Най големият бонус е че не се налага рестартиране на системата или вадене и правене на допълнителни масиви.

sfdisk -d /dev/sdb | sfdisk /dev/sdc
mdadm --grow /dev/md0 --level=5
mdadm --manage /dev/md0 --add /dev/sdc
mdadm --grow /dev/md0 --raid-devices=3
resize2fs /dev/md0

Лека вечер 😛

Подготвяме нова услуга за хостинга и по време на тестовете при опит за свръзка между WHMCS и Cloudmin имахме следната грешка

CURL Error: 7 – couldn’t connect to host

 

Забавно веднага проверявам връзката между машините където е WHMCS-a и Cloudmin-а всичко работи. Проверявам 10000-ния порт и той отворен и достъп до него има 🙄 . Забавно!

Правя един бърз  на cloudmin сървъра


tcpdump -i br0 host WHMCS_IP

и за мое (не много голямо) изумление гледам че се опитва да се свърже на 80-ти или 443 (ако е активиран SSL) портове без да ме пита за такъв. По подразбиране webmin-a и cloudmin-a който е приложение към първия работят на SSL 10000 порт. Понеже тая глупава система е IonCube криптирана няма как да си едитна кода че да им оправя индииските глупости та се налага по радикален подход. Преди да напусне системата подменям порта на дестинацията с iptables


iptables -t nat -A OUTPUT -d cloudmin_ip -p tcp -m tcp --dport 443 -j DNAT --to-destination cloudmin_ip:10000

където заменяте cloudmin_ip с IP-то на вашата cloudmin инсталация. След тая дребна манипулация връзката между WHMCS и Cloudmin се осъществи, но модула продължава да има и други проблеми освен този 😆 :mrgreen:

В общи линии за година ползване на WHMCS съм крайно разочарован от него – доста е дървен, поддръжката на support екипа е бавна, документацията на кода и разни други неща се разминава с реалността, доста голямо количество бъгове и е доста дървен. Ако знаех че е толкова зле бих предпочел да го ползвам с нулиран лиценз вместо да се дадат 300$ за нещо което работи някак!

http://www.youtube.com/watch?v=GF2-TKfQOsk