BG Tech Blog

Лесно е, със следните няколко реда:

sudo mkdir /media/iso
sudo mount -t iso9660 filename.iso /media/iso -o loop
ls -la /media/iso

Наскоро пуснах и инсталирах (успешно!) една Amazon EC2 инстанция (машина/сървър).
Проблема ми беше, че при избор на въпросната инстанция имаше само падащо меню с имената им и пълното описание липсваше. Естествено “скрито” в документацията… кой чете документация в днешно време?
Ето пълното описание на Amazon EC2 инстанциите. Текста е copy/paste от Amazon

Standard Instances

Instances of this family are well suited for most applications.

Small Instance

1.7 GB memory
1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)
160 GB instance storage (150 GB plus 10 GB root partition)
32-bit platform
I/O Performance: Moderate
API name: m1.small

Large Instance

7.5 GB memory
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)
850 GB instance storage (2×420 GB plus 10 GB root partition)
64-bit platform
I/O Performance: High
API name: m1.large

Extra Large Instance

15 GB memory
8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
1,690 GB instance storage (4×420 GB plus 10 GB root partition)
64-bit platform
I/O Performance: High
API name: m1.xlarge

High-Memory Instances

Instances of this family offer large memory sizes for high throughput applications, including database and memory caching applications.

High-Memory Extra Large Instance

17.1 GB of memory
6.5 EC2 Compute Units (2 virtual cores with 3.25 EC2 Compute Units each)
420 GB of instance storage
64-bit platform
I/O Performance: Moderate
API name: m2.xlarge

High-Memory Double Extra Large Instance

34.2 GB of memory
13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each)
850 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.2xlarge

High-Memory Quadruple Extra Large Instance

68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.4xlarge

High-CPU Instances

Instances of this family have proportionally more CPU resources than memory (RAM) and are well suited for compute-intensive applications.

High-CPU Medium Instance

1.7 GB of memory
5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each)
350 GB of instance storage
32-bit platform
I/O Performance: Moderate
API name: c1.medium

High-CPU Extra Large Instance

7 GB of memory
20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: c1.xlarge

Преди няколко дни пуснах Windows Server на VPS. Проблема на Windows сървърите е, че не можеш да ги управляваш от конзола (или поне аз не знам как става) и за целта трябваше да се свържа с remote desktop към машината и да си играя с нея.
Тъй като съм на Ubuntu от… от много много време и нямам windows remote desktop софтуер трябваше да потърся малко. Най-доброто решение, което намерих след известно време в google беше rdesktop. Много удобна и лесна за използване програмка, която дори можете да инсталирате от репозиторито на Ubuntu.

Начин на използване:

rdesktop 192.168.1.1

Днес трябваше да използвам imagemagick за да създам картинка с текст. Уловката беше, че трябва да се добавят различни шрифтове, с които да работи convert-а.
Създаваме папка, в която ще сложим новите шрифтове:

mkdir -p /usr/share/fonts/mynewfonts/

След това прекешираме шрифтовете, а в Debian това става със следната команда:

sudo fc-cache -f -v

И готово

Текущата команда изтрива файлове по-стари от 360 минути.

find $LOCATION -name $REQUIRED_FILES -type f -mmin +360 -delete

$LOCATION - път от където да започне търсенето на файловете
$REQUIRED_FILES – име (regex) за търсене на файлове

Преди известно време трябваше да се синхронизират файлове от една машина към втора. Проблема беше, че втората машина бе вътрешна за определена мрежа и през нея можеше да се достигне само чрез трета машина, която служеше в случея като буфер между двете.
Решението беше на буферната машина да се “вдигне” SSH тунел и връзката да се осъществи буквално през нея.

Вдигането на тунел в ssh не е от най-трудните неща и се постига доста лесно, с една команда:

ssh -f blagomir@casper -L 123:blagomir.com:456 -N

-f означава, че ssh процеса ще се пусне в background
-L 123 – процеса ще слуша на порт 123

Цялата команда се тълкува по следния начин:
ако потребител blagomir на машина casper (тук се пише IP на машината, вместо името й) се свързва през порт 123, той се пренасочва към порт 456 на машина blagomir.com

Ако никога до сега не е била сетвана парола, можете да го направите по този начин:

mysqladmin -u root -p PASSWORD

Ако искате да смените вече заложена парола:

mysqladmin -u root -pOLD_PASSWORD password 'NEW_PASSWORD'

Например ако паролата ви е 123 и искате да я смените на 456, това ще изглежда така

mysqladmin -u root -p123 password '456'

Можете да смените паролата и с SQL команда:

USE mysql;
UPDATE user SET password=PASSWORD("NEWPASSWORD") WHERE User='root';
FLUSH privileges;

Наскоро намерих стари забрвени log файлове пълни с вече ненужна информация. Съответно трябваше да се предприемат мерки по изтриването им. Проблема беше в количеството на файловете – около 211 GB, състоящи се от повече от 600 000 файла. Самото изтриване трябваше да стане без да се натоварва машината, защото все пак е production server и не трябва да се нарушава работата му.

Започнах по най-стария и лесен начин, а именно:

rm logs/ -r

За около 1 минута load avearage на машината се качи от 1 до 16. Да, тук някой от вас ще кажат, че load-а не е определящ фактор, но все пак е някаква цифра, по която може да се водим за оптималната работа на сървъра.
Значително се усещаше натоварването при работа със сайта. Всичко се случваше изключително бавно, MySQL заявките се изпълняваха за невъзможни времена от сорта на +1 сек.
Опитах да пусна същата команда, но с различен nice:

nice -n 10 rm logs/ -r

Това просто отложи натоварването. След около 10 мин пак имаше проблем с машината и трябваше да търся ново решение. След кратко ровене в google, намерих няколко статии, гласящи, че може да се направи нещо като unlink на самата директория и тя да изчезне заедно с файловете в нея за около секунда Да, но не. При подобно изтриване на директория/файлове, те не се изтриват физически от диска, а просто системата вече не линква към тях. Следователно не се освобождава място на диска. Другият възможен проблем е, че при рестартиране на машината, като се пусне fsck ще се опита да оправи проблемите, а именно да изтрие файловете, към който няма “референции”. Това може да доведе до счупване на цялата файлова система и да си навлечете още по-големи проблеми.

Моят съвет е – изтриите си файловете. Може да отнеме повече време (1-2-3 дни), но ще сте сигурни, че няма да имате проблеми в последствие.

Преди около седмица се изправих пред поредния “невъзможен” проблем. Незнайно как, auto_increment полето в една от таблиците се нулираше само. По първи впечатления това се случваше на произволен интервал от време, но по-късно разбрах, че причината е в един определен cron.
Въпросният cron има за цел да оптимизира и подреди базата данни. Общо взето може да се каже, че е garbage collector за доста от нещата в базата. След съответните зачистващи процедури пуснах и процедура за оптимизиране на таблиците, а именно “OPTIMIZE table X”, където Х е името на всяка една от нужните таблици.
За моя голяма изненада, след 3 дни проблеми и опити да реша проблема, се оказа, че когато правите OPTIMIZE на InnoDB таблица, auto_increment полето в нея се нулира. За справка можете да погледнете този bug report в MySQL Bugs.