Утилиты Linux о которых мало кто знает но пользуется

Утилиты Linux о которых мало кто знает но пользуется

В Linux есть ряд инструментов с интересным состоянием: почти каждый хоть раз видел результат их работы, но мало кто знает, как это было сделано. В этой статье представлены некоторые из этих инструментов и утилит.Так же сдесь мы рассмотрим некоторые скрипты и утилиты Linux.

 

Генератор паролей

Генераторов паролей сейчас в изобилии. Особенно удивительно то, что для этой цели существует множество веб-приложений. Сервис random.org честно признает, что генерирует пароли на стороне сервера и использовать их для чего-либо серьезного противопоказано. Другие сервисы заявляют, что генерируют пароли локально с помощью JavaScript, но поверить им на слово и гарантировать ли их подход, что утечки безопасны, непросто.

При этом генератор случайных паролей присутствует в репозиториях всех дистрибутивов утилит Linux с 90-х годов и называется pwgen. Большинство паролей, которые вы получали в своей жизни, вероятно, были созданы им.

Что инте­рес­но, его автор — Те­одор Цо, тот самый, который раз­работал фай­ловую сис­тему ext2 и ее жур­налиру­емые вер­сии ext3 и ext4.

К при­меру, pwgen 16 1 сге­нери­рует один пароль из шес­тнад­цати сим­волов.

$ pwgen 16 1

iy1naeZeeNguchae
 
Если вы не укажете второй аргумент (количество паролей), по умолчанию в интерактивном режиме pwgen сгенерирует до восьмидесяти паролей — четыре столбца по двадцать строк. По замыслу авторов, это должно защитить пользователя от тех, кто любит смотреть на экран другого человека. Пользователь генерирует всю таблицу паролей и копирует или запоминает из нее один случайный. В этом случае злоумышленник или чрезмерно любопытный коллега по офису не сможет узнать, какой пароль из восьми десятков выбрал пользователь. Сейчас век массовой удаленной работы и этот аргумент кажется немного напряженным, и сомнительно, что пароли так легко запомнить.
 

В сов­ремен­ных усло­виях куда полез­нее опция -s/--secure, которая генери­рует пол­ностью слу­чай­ные пароли без пре­тен­зий на удо­бочи­таемость. К ней же мож­но добавить -B/--ambiguous, которая исклю­чает из вывода похожие на вид сим­волы вро­де O/0 и 1/I.

$ pwgen -sB 16 1
PiVRps3erAngsmeb
 

Самораспаковывающиеся архивы

Проприетарные утилиты Linux часто распространяются как исполняемые установщики. Таким образом, их авторам не нужно компилировать более одного формата пакета. Программы на независимых от платформы языках, таких как Java, также могут использовать один и тот же графический установщик во всех операционных системах — способ их запуска отличается.

Та­ким спо­собом рас­простра­нялись файлы с драй­верами NVIDIA, некото­рые игры, зна­читель­ная часть пакетов Sun Microsystems / Oracle (NetBeans, SunStudio и дру­гие). Чаще все­го у них было рас­ширение .run, иног­да прос­то .sh.

Что представляет собой установщик

Обычно этот установщик представляет собой самораспаковывающийся архив. В Windows монолитные установщики и самораспаковывающиеся архивы часто содержат двоичный код для распаковки архива. UNIX-подобные операционные системы всегда включают по крайней мере tar и gzip форматы, как того требует стандарт POSIX, поэтому вы можете работать со сценарием в стандартной оболочке Bourne.

Я дол­го думал, что инс­тру­мен­ты для соз­дания этих уста­нов­щиков тоже проп­риетар­ные. Так бы я и думал, если бы не нат­кнул­ся на сво­бод­ные про­екты с такими же уста­нов­щиками. Соз­дателем этих форматов ока­зал­ся один и тот же инс­тру­мент с откры­тым исходным кодом — Makeself.

Makeself — относительно небольшой формат скрипта. Как ни странно, авторы все еще не отказались от этого, и в последних версиях Makeself поддерживает сжатие xz и контрольные суммы SHA-256 вместо традиционных gzip и MD5.

Мож­но даже не уста­нав­ливать его, а прос­то ско­пиро­вать фай­лы makeself.sh и makeself-header.sh в каталог про­екта. Про­демонс­три­рую на прос­том при­мере. Нам пот­ребу­ется целевой файл (условно test.sh) и скрипт уста­нов­ки, который будет выпол­нять­ся пос­ле рас­паков­ки во вре­мен­ный каталог.

├── makeself-header.sh
├── makeself.sh
└── my-package
├── setup.sh
└── test.sh

Процесс установки полностью зависит от пользователя. Для простоты ограничимся копированием в / tmp. Скрипт выполняется в каталоге с разархивированными файлами, поэтому все пути относительны.

#!/bin/sh

cp test.sh /tmp/
 
Те­перь соз­дадим наш уста­нов­щик. Син­таксис коман­ды — makeself.sh <каталог с файлами> <имя выходного файла> <название проекта> <команда для выполнения после распаковки>.
Путь к команде, выполняемой после распаковки, также записывается относительно каталога, содержащего распакованные файлы. Это единственная тонкость работы с Makeself. Вот почему мы поместили сценарий setup.sh в каталог пакета — Makeself рассматривает этот аргумент как команду, а не встраивает сценарий в заголовок установщика.

$ ./makeself.sh ./my-package/ my-package.run "My Package" "./setup.sh"
Header is 678 lines long

About to compress 12 KB of data...
Adding files to archive named "my-package.run"...
./setup.sh
./test.sh
CRC: 2448166092
MD5: f46655bb0b96ea7bee4d1f6f112eebe4

Self-extractable archive "my-package.run" successfully created.

$ ./my-package.run
Verifying archive integrity... 100% MD5 checksums are OK. All good.
Uncompressing My Package 100%

$ file /tmp/test.sh
/tmp/test.sh: POSIX shell script, ASCII text executable

Есть ли смысл использовать Makeself во вре­мена snap, Flatpak и AppImage? Я вижу два варианта, в которых собственный статус по-прежнему важен. Первый — распространять самоустанавливающиеся патчи в особых случаях, когда создание обычного пакета невозможно или нецелесообразно. Второй — поддержка проприетарных операционных систем. Автономные сценарии с параметрами по умолчанию будут работать в любой POSIX-совместимой системе, поэтому, если вам нужен установщик для Solaris или HP-UX, это самый простой способ их создания.

Малоизвестные форматы архивов

Некоторые форматы архивов достигли пика популярности и теперь ушли в прошлое. Традиционно UNIX использует разные инструменты для создания архива (то есть для объединения нескольких файлов в один) и сжатия. Из-за этого инструменты сжатия могут появляться и устаревать, не вызывая проблем — нет необходимости оставлять поддержку устаревших алгоритмов в новых архиваторах. Если вам нужно распаковать данные по старому алгоритму, вы всегда можете установить отдельную утилиту.

Ес­ли в ходе архе­оло­гичес­ких рас­копок тебе попадет­ся файл .tar.Z, мож­но пос­тавить ncompress и выпол­нить compress -d file.tar.Z, пос­ле чего понадо­бит­ся толь­ко стан­дар­тный tar. В дру­гих слу­чаях ори­гиналь­ный алго­ритм LZW никому в голову не при­дет.

Другое дело с реальными форматами архивов. В отличие от алгоритмов сжатия трудно сравнивать способы сборки файла из нес­коль­ких слож­но срав­нивать меж­ду собой. Формат ZIP не поддерживает права доступа к файлам, в то время как tar поддерживает, в этом смысле tar.gz лучше, чем ZIP. В то же время, довольно трудно найти формат, который объективно и, несомненно, лучше, чем tar.

Од­нако есть фор­мат фай­ла, а есть инс­тру­мен­ты для работы с ним. И поведе­ние tar, и фор­мат соз­дава­емых фай­лов стан­дарти­зова­ны в POSIX, что и дела­ет его популяр­ным на всех UNIX-подоб­ных сис­темах. К тому же ути­лита tar дос­таточ­но удоб­на в исполь­зовании. По край­ней мере tar cvf и tar xvf быс­тро запоми­нает каж­дый поль­зователь.

cpio

Ты уди­вишь­ся, но tar — это не самый рас­простра­нен­ный фор­мат архи­вов в Linux. Сре­ди поль­зовате­лей — да, но боль­ше все­го дан­ных хра­нит­ся в фор­мате cpio, с которым ред­ко при­ходит­ся работать вруч­ную.

Почти все машины c Linux имеют файл в этом формате, так как это то, что ядро ​​использует для initrd (начального RAM-диска). Он также используется в формате пакета RPM. Как сказано в документации к ядру, решающим фактором была простота формата.

А вот поль­зовать­ся ути­лита­ми, которые с ним работа­ют, сов­сем не прос­то. Вот как надо вызывать ути­литу cpio, что­бы соз­дать архив:

find /path/to/dir -depth -print | cpio -o > /path/to/archive.cpio

Для скрип­та сбор­ки — сой­дет, даже в чем‑то удоб­но. Для руч­ного исполь­зования… tar cvf явно про­ще и пок­рыва­ет боль­шую часть пот­ребнос­тей поль­зовате­ля.

Для скрип­та сбор­ки — сой­дет, даже в чем‑то удоб­но. Для руч­ного исполь­зования… tar cvf явно про­ще и пок­рыва­ет боль­шую часть пот­ребнос­тей поль­зовате­ля.

Для скрип­та сбор­ки — сой­дет, даже в чем‑то удоб­но. Для руч­ного исполь­зования… tar cvf явно про­ще и пок­рыва­ет боль­шую часть пот­ребнос­тей поль­зовате­ля.

Для скрип­та сбор­ки — сой­дет, даже в чем‑то удоб­но. Для руч­ного исполь­зования… tar cvf явно про­ще и пок­рыва­ет боль­шую часть пот­ребнос­тей поль­зовате­ля.

ar

Другой распространенный формат, который никто не использует напрямую, — это ar. Его реализация включена в пакет GNU binutils. Как он попал в пакет с утилитами Linux88 для работы с исполняемыми файлами? Дело в том, что он используется для создания статических библиотек.

В ELF нет специального формата «статической библиотеки». Каждый исходный файл компилируется в отдельный объектный файл в том же формате ELF. Такие файлы, как libfoo.a, на самом деле представляют собой архивы ar, содержащие несколько объектных файлов.Таким обра­зом, поль­зователь может писать gcc -o myprog myprog.o /usr/lib/foo/static/libfoo.a.

Вто­рой поль­зователь это­го фор­мата — пакет­ный менед­жер dpkg. Если файл .rpm — это сжа­тый cpio, то .deb — сжа­тый ar.

Внешние отладочные символы

Один из пер­вых уро­ков начина­юще­го раз­работ­чика для UNIX: хочешь сде­лать исполня­емый файл мень­ше — выпол­ни strip myfile. Ценой потери воз­можнос­ти работы с ним в отладчи­ке, конеч­но.

Со вре­менем начина­ющий обя­затель­но уви­дит в репози­тори­ях пакеты с внеш­ними отла­доч­ными сим­волами. Как они дела­ются? С помощью ути­литы Linux objcopy из Binutils.

Рас­смот­рим на при­мере тра­дици­онной прог­раммы Hello world.

#include <stdio.h>

 
int main(void) {
printf("hello world\n");
}
 

Ском­пилиру­ем исполня­емый файл с отла­доч­ной информа­цией.

$ gcc -g -o hello ./hello.c
[dmbaturin@careless makeself-test]$ file ./hello
./hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a8e65e032c2a154eecc1ed609aac1a1687e5c2fd, for GNU/Linux 3.2.0, with debug_info, not stripped

Те­перь извле­чем отла­доч­ные сим­волы во внеш­ний файл hello.debugи уда­лим их из исходно­го.

$ objcopy --only-keep-debug ./hello hello.debug

$ file ./hello.debug
./hello.debug: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter empty, BuildID[sha1]=a8e65e032c2a154eecc1ed609aac1a1687e5c2fd, for GNU/Linux 3.2.0, with debug_info, not stripped

$ ldd ./hello.debug
statically linked

Ес­ли запус­тить исходный файл в отладчи­ке GDB, мы получим сооб­щение об отсутс­тву­ющих отла­доч­ных сим­волах. Но если заг­рузить сим­волы коман­дой symbol-file hello.debug, мы смо­жем отла­живать его как обыч­но.

$ gdb ./hello
GNU gdb (GDB) Fedora 9.1-6.fc32

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello...
(No debugging symbols found in ./hello)

(gdb) symbol-file hello.debug
Reading symbols from hello.debug...

(gdb) b main
Breakpoint 1 at 0x40112a: file ./hello.c, line 4.
(gdb) r
Starting program: /home/dmbaturin/tmp/hello

Breakpoint 1, main () at ./hello.c:4
4 printf("hello world\n");
(gdb)

Заключение

Вы можете не найти ни один из этих инструментов и утилит Linux полезным. А может вам просто их не хватало.Или не хватает для того, кто придет к вам завтра. И задаст вопрос «а чем сделали этот файл?» В любом случае лучше знать их, чем не знать!

 

Click to rate this post!
[Total: 2 Average: 5]

Leave a reply:

Your email address will not be published.