Tag: linux

10.09.2024

Ха, uptime robot ми светна, че сайта е бил долу през вечерта със супер информативното съобщение – “There has been a critical error on this website”. Любопитно, но се оказа, че го е счупил един google plugin, който не възнамерявам да връщам обратно.

Набързо за white screen of death и стъпките за дебъгване:

  1. Проверка на това колко свободно място на диска и в RAM паметта имаме:
marvinator@marvin $ free -m
total used free shared buff/cache available
Mem: 1967 1752 66 64 368 214
marvinator@marvin $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 25G 18G 6.1G 74% /
/dev/vda15 124M 12M 113M 10% /boot/efi

Тук виждаме, че място на диска има, но имаме само 66MB свободна рам. Рестартирах нормалните виновници и по-точно MariaDB и php-fpm:

marvinator@marvin $ systemctl restart mariadb.service
marvinator@marvin $ systemctl restart php8.2-fpm.service

Да видим колко памет имаме освободена:

marvinator@marvin $ free -m
total used free shared buff/cache available
Mem: 1967 738 990 55 450 1229

Така е по-добре, от 66MB към 738MB. Това не е перманентно решение и ще трябва да си оптимизирам малко сървисите, но за сега – толкова.

2. Това не помогна да се реши проблема така, че отиваме в логовете на nginx (които взимаме от /etc/nginx/conf.d/{default}.conf) ей така (ако файла се казва default.com):

marvinator@marvin / $ cat /etc/nginx/conf.d/default.conf | grep "error.log"
error_log /var/log/nginx/nedko.info.error.log;

Правим един tail и с него гледаме какво се случва във файла след като refresh-нем страницата и ето го зайчето:

marvinator@marvin / $ tail -f /var/log/nginx/default.error.log

2024/09/10 07:58:14 [error] 2704424#2704424: *2661604 Failed to open stream: No such file or directory in /xxx/xxx/wp-content/plugins/google-site-kit/includes/loader.php on line 62;

Вероятно е минал някакъв ъпдейт, който е потрошил плъгина и оттам WordPress е изпаднал в паника. Решението ми беше да преместя или изтрия директорията от plugins и така да позволя на WordPress да си се зареди правилно.

Takeaways:

  1. Трябва да повече оптимизирам сървисите, които имам и да спра тези, които не използвам
  2. Трябва да спра (вече е направено) автоматичните ъпдейти на плъгините. Бях пуснал само тях преди време (без ъпдейт на WordPress core), но беше въпрос на време нещо да се наака
  3. Безплатния tier на UptimeRobot за веченезнамкойпът си върши работата чудесно.

How to view jar version with unzip

Набързо пиша са future self, че ако искам да видя каква версия на application-а съм деплойнал може да стане лесно с unzip и по-специално с:

# unzip -q -c example-app.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Implementation-Title: example-app
Implementation-Version: 1.23.4
Start-Class: com.example.example.app.ExampleApp
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Build-Jdk-Spec: 1.8
Spring-Boot-Version: 3.2.1.RELEASE
Created-By: Maven Archiver 3.6.1
Implementation-Vendor: example
Main-Class: org.springframework.boot.loader.JarLauncher

И виждаме, че използваме версия 1.23.4. Супер удобно както в моя случай като администрирам доста различни Java сървиса и непременно в някакъв момент започват едни – кой какво е деплойнал, къде ,ама как, кога и подобни.

Можете да направите и в един oneliner връщайки само версията:

# unzip -q -c example-app.jar META-INF/MANIFEST.MF | grep 'Implementation-Version' | cut -d ':' -f 2
2.13.4

бтв докато писах последното изречение – ако се наложи да инспектирате например кога е направена последната промяна по някой конкретен файл или искате малко повече инфо можете да използвате stat:

# stat example-app.jar
  File: ‘example-app.jar’
  Size: 90837539        Blocks: 177424     IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 8669310     Links: 1
Access: (0500/-r-x------)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:usr_t:s0
Access: 2024-01-10 10:53:52.964543333 +0100
Modify: 2024-01-10 10:53:33.700533240 +0100
Change: 2024-01-10 10:53:33.700533240 +0100
 Birth: -

12.11.2023

Marvinator-а, брат на marvin, който съвсем скоро вдигнах имаше нужда от мониторинг. И тръгвам аз да инсталирам prometheus/alertsmanager/grafana и в един момент започнах да смятам колко рам ще ми е нужна. И понеже съм скръндза реших да изнеса целия мониторинг към Grafana.com и да им използвам безплатния tier, който като единствен минус към момента ми е, че metrics & log retention-а ми е само 14 дни, но yolo.

Инсталацията на агента, който е единственото нещо, което живее на моя хост е бърза и лесна, а откъм потребление към момента е около 140 MB RAM. Ако бях хостнал локално целия стак щеше със сигурност да бъде много повече.

A project of the day отива при tuning-primer – bash скрипт, който дава добър анализ на mysql/mariadb бази. Нужни са само root user/pass към базата и като резултат ви изплюва всичко, което му е харесало и което не е ок. Има доста данни покрай анализите и можете да си направите един добър fine tuning.

06.12.2022

Днес попаднах на една много яка репрезентация какво се случва след като напишете някой адрес, например https://google.com в браузъра си

Забележително е през колко стъпки минава нещо толкова елементарно за нас, а още по-забележителното е, че това нещо работи и то доста стабилно. А най-забележителното е (госпожата по литература да ме извини за тези сравнителни определения), че това отнема милисекунди. Ми-ли се-кун-ди.

Понякога се замислям за нещата, които приемаме за даденост и за това колко тежки имплементации има отдолу, колко умни глави са се сблъсквали със супер интересни проблеми и са им намирали най-елегантните (в повечето случаи) решения. За това как едни отворени и безплатни проекти като nginx и apache задвижват 66% от общия HTTP/S трафик, как една линукс дистрибуция, която можем да теглим, инсталираме и модифицираме безплатно съдържа в себе си труда на хиляди хора, как имаме linux инструментариум написан и поддържан от 70-те години до сега (например първия релийз на grep е направен през 1973 г.). Трябва да се присещаме за тези неща и да сме благодарни, защото иначе няма как да си скролваме фейсбука в 03:00 през нощта.

aws zsh autocomplete

Един бърз writeup как да си подкарате безспорно (безпорно?) мегаудобството aws cli completition (тоест като напишете aws s3 l да ви покаже всички коменди в този namespace) под macos. Как да го инсталирате можете да прочетете тук.
В документацията на aws го има описано в повече детайли, но meat-а е само да добавите в .zshrc следните редове:

# Path to aws_completer
export PATH=/usr/local/bin/:$PATH

autoload bashcompinit && bashcompinit
autoload -Uz compinit && compinit
complete -C '/opt/homebrew/bin/aws_completer' aws

След това за да избегнем стъпката с logout или рестарт можем просто да презаредим файла наново (един хубав плюс е и това, че ако нещо не сме paste-нали правилно или пътят към aws_completer-а е грешен ще получим и съответното съобщение и ще ни спести малко време вместо да рестартираме при всяка промяна да речем):

source ~/.zshrc

Сега е време за тест, да опитаме да изкараме списък с всички ec2 instances (без значение от state-а им):

aws ec2 describe-instances --output json | jq

Малко е трудно да направя демо на това, но като напишете aws ec2 des[TAB] и ще ви покаже всички възможни опции. След като изберете нещо конкретно можете да продължите със следващия параметър, в случая –output. Неудобното е, че не suggest-ва и опциите по параметрите (в случая те са json, table, yaml-stream, text, yaml), което приемам за неудобство, но и разбирам, че не би работило това навсякъде (представете си autocomplete-а да прави requests към вашите ресурси (дай всички ec2 инстанции, после дай всички тагове и т.н.). Би било епично, но не виждам това да бъде възможно скоро време. Та ако имате инсталиран jq бихте видели output с всички параметри по EC2 инстанцията (които са десетки). За по-лесна визуализация можете да използвате –query параметъра и да изкарате нещо подобно:

aws ec2 describe-instances \
--query "Reservations[*].{ \
OwnerID:OwnerId, \
IP:Instances[0].PublicIpAddress, \
InstanceID:Instances[0].InstanceId, \
AvailabilityZone:Instances[0].Placement.AvailabilityZone, \
InstanceState:Instances[0].State.Name, \
KEY:Instances[0].KeyName, \
VPC:Instances[0].VpcId, \
InstanceType:Instances[0].InstanceType \
}" --output json | jq

И съответния output:

[
{
"OwnerID": "255875099999",
"IP": null,
"InstanceID": "i-074db48e5a4a4a4a4",
"AvailabilityZone": "eu-west-1a",
"InstanceState": "stopped",
"KEY": "nedko",
"VPC": "vpc-0cb7fb97b97b97b97",
"InstanceType": "t3.micro"
}
]

–query е мощно средство ако искате да автоматизирате през aws cli или искате да дебъгвате нещо определено и по ред причини не използвате AWS CloudWatch да речем. Аз например имам един gistс няколко craft-нати spell-а за различни кейсове, които са ми били нужни през годините и когато имате 20-30-40 инстанции (или ресурса, тук пиша в контекста на EC2, но cli console-а може да се използва практически навсякъде) може да ви улесни живота с много.

19.05.2022 – git и търсене по commit

Днес ми се наложи да търся дали някой commit е влязал в tag-ната версия в git и понеже е лесен onliner споделям с вас.

Отбелязка, че много зависи какъв ви е git workflow-а. Проектът, който си избрах на рандом е този – gRPCurl.

Та имаме commit ID да речем 8ee6c9. Единия начин е да отидем в Releases на проекта и да търсим на ръка в ляво, изглежда ей така:

Но вече се досещате, че ако работите в някой огромен проект не можете да търсите на ръка 150 страници с релийзи, а за това идва в помощ git cli tool-a:

[email protected]:[~/repo/code/grpcurl] $ git log --oneline | grep "8ee6c94"

8ee6c94 can't build s390x docker images; skip for now (#265)

Ето, че виждаме съобщението, а сега вадим и таг-а:

[email protected]:[~/repo/code/grpcurl] $ git tag --contains 8ee6c94 | head -1
v1.8.5

Без head -1 вади всички тагове, които съдържат този commit (благодаря на Владо за дописването и коригирането)

[email protected]:[~/repo/code/grpcurl] $ git tag --contains 8ee6c94 | head -1
v1.8.5
v1.8.6

19.03.2022

Така както съм започнал ще обърна блога на tutorial сайт (в което няма нищо лошо).
Използвате ли vim в ежедневието си? Знаете как да излезете от него? Чудесно, този пост е за вас.

Наложи ми се днес да заменя много стрингове с други такива та реших да го направя под vim и споделям с вас.

Отваряме файла, който искаме да редактираме и натискаме : (за да влезем в режим на приемане на команди, баси комунистическото прозвуча):

%s/False/true/g

Този regex ще потърси целия файл за стринг False и ще го промени на True. Може и само ред по ред, а не всички наведнъж като махнете /g накрая, а можете и да му кажете само върху кои редове да направи промяната с:

:6,10s/False/True/g

18.03.2022

Искам да накарам диска ми да се mount-ва автоматично при стартиране на ubuntu-то та реших да споделя ако някой има нужда от долните редове:

sudo fdisk -l

От списъка намирам, че диска, който търся е sdb, a partition-а му е sdb1:

Disk /dev/sdb: 5,47 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: ST6000DM003-2CY1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: C2683872-ECAF-4306-8170-73D16C6CE475

Device     Start         End     Sectors  Size Type
/dev/sdb1   2048 11721043967 11721041920  5,5T Linux filesystem

След това намирам UUID-то на partition-а (може и с името ѝ, в случая /dev/sdb1, но това не е добра идея по много причини):

$ sudo blkid
/dev/sdb1: UUID="fe490c8e-ac32-442a-2dfc-8e089131e048" TYPE="ext4" PARTLABEL="Storage drive" PARTUUID="6b1f3ab3-a009-43d8-8fc4-d8e456acc717"

И добавяме на нов ред в /etc/fstab

UUID=fe490c8e-ac32-442a-2dfc-8e089131e048 /mnt/bigDrive ext4    defaults        0       2

Като разбира се променяме UUID и mount point-а, който при мен води до /mnt/bigDrive.

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

$ sudo mount -av
/                        : ignored
/boot/efi           : already mounted
none                 : ignored
/mnt/bigDrive   : successfully mounted

Туй то.

Добре, че не станах системен администратор

Днес се самообявих за най-големия олигофрен, който познавам.

Мигрирам marvin от един VPS provider към друг и изведнъж достъпа ми до стария VPS по SSH спря. И не мога да се логна нито от офиса нито от нас. И писах едни мейли, една кореспонденция, едно чудо.
И успявам да се закача за console applet-а , но не мога да прехвърля файловете си през SSH.

ДВЕ СЕДМИЦИ. Две седмици ми отне да се сетя, че имам fail2ban, който явно не съм конфигурирал или съм конфигурирал по някакъв тъп начин и съм си blacklist-нал сам достъпа до двете IP-та.

За тези на които хипоталамуса им изтръпва при този проблем – четете долните редове. Ако сте сисадмин и знаете отговора – затворете сайта и никога повече не влизайте. All the shame…

Та – играта ви е в:

/etc/hosts.allow

/etc/hosts.deny

Влизате с нужните права в /etc/hosts.deny и вижте вашето IP дали не е там. Ако е – можете да го коментирате и да го добавите в /etc/hosts.allow.

03.01.2018

Зъб. Цяла вечер ме боля, мамицата му. Смятах в един момент да взема клещите и да стигна до саморазправа.

 

In other news:

  • DRAMA-та се задълбочава. TheRegister описаха случая и няколко техни теста. И един туит описващ всичко:

  • Оказа се, че много online services of GPS location tracking са vulnerable. В общи линии трето лице може да проследи физически клиентите, които използват тези сървиси (описани са в статията). Оказа се също и че някои от провайдърите са идиоти, защото паролите им по подразбиране са 123456.