powerman
+2
> Я уверен на 99,9%, что все разработчики и ПМ, имеющие авторизации в C/C++ и не только, после бюллетня от Интела и описания уязвимости, проверили свои кейсы на наличие теста пароля с нулевой длинной.

Просто Вы — романтик. А на практике те разработчики, которые беспокоятся о безопасности, ничего проверять не стали, потому что у них давно поставлены процессы и выработано определённое отношение к коду, при котором такие баги не проходят, а если и проходят, то в настолько неочевидных случаях, что просматривать быстренько код после чтения статьи на хабре бессмысленно. А те разработчики, которые о безопасности особо не задумываются — тоже не побегут ничего проверять, потому что им тупо пофигу.
powerman
0
наличие такой дыры делает очень вероятным наличие других дыр

Наличие «такой дыры» обозначает всего лишь недостаточное тестирование.

С точки зрения менеджера или админа — да. Потому что оценивается причина, по которой ошибка попала в продакшн.

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

Понимаю Вашу мотивацию и нежелание отключать AMT, но наличие такой дыры делает очень вероятным наличие других дыр. Не знаю, есть ли они там на самом деле, была ли эта ошибка следствием трагической случайности или системного подхода "пофиг на безопасность" — но сейчас куча людей набросилась на новый лакомый кусочек в поисках новых дыр… или набросятся, как только эксплуатация этой дыры перестанет приносить достаточные дивиденды. Так что до проведения (желательно — публичного) внешнего аудита безопасности исходников AMT держать системы с доступом к AMT из интернета — значит нарываться на неприятности.

powerman
–4

И чем мне это поможет? Ставить ради этого dosbox, который всё-равно не получит доступ к портам из-за grsecurity?

powerman
0

Я там выше приводил ссылку на описание чипсета, и там сказано:


Intel® vPro™ Technology: No
Intel® ME Firmware Version: No
powerman
–1

Действительно, в ядре есть драйвер "Intel Management Engine Interface" и созданное им устройство /dev/mei0.


Устройств с указанными ID я не вижу, но есть вот это:


00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
        Subsystem: Gigabyte Technology Co., Ltd 6 Series/C200 Series Chipset Family MEI Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 25
        Region 0: Memory at f6607000 (64-bit, non-prefetchable) [size=16]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000feeff00c  Data: 41c1
        Kernel driver in use: mei_me

Упомянутая flothrone тулза MEInfo есть только под винду. Но я нашёл /usr/src/linux/Documentation/misc-devices/mei/mei-amt-version.c — теоретически она должна сказать активен ли AMT и показать его версию. Практически же она во-первых пытается работать с /dev/mei вместо /dev/mei0 (но это я поправил) и во-вторых выдаёт ошибку при попытке вызвать первый же ioctl после открытия /dev/mei0:


# ./mei-amt-version                                                                 
Error: IOCTL_MEI_CONNECT_CLIENT receive message. err=-1

В общем, странно всё это. Что-то вроде формально есть, но работать — не работает.

powerman
–1

Я не знаю, что на материнки с этим чипсетом ставится под винду, у меня линух и таких драйверов нет. Но даже если он ставится — не факт, что он реально работает, а не отвечает "no such device" на любые запросы.

powerman
–1
ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше.

Даже SemiAccurate не утверждает этого наверняка. Вы более информированы на этот счёт? Есть пруфы или данное утверждение базируется на глубокой внутренней уверенности?


Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен.

Не совсем понял, как может быть "активен" ME, если судя по официальной спеке Intel ME отсутствует на этом чипсете и даже по Вашим словам AMT выключена. Как можно проверить, что ME есть и даже активен?

powerman
–1

Тон там немного истеричный (хоть и не без причины), но в целом очень интересно было почитать, спасибо. Насчёт "любая система выпущенная за последние 10 лет" — у меня (десктопная) материнка 5-ти летней давности на Intel® Z68 Express Chipset, и судя по спеке интела там ME нет вообще.


В следующей статье разбирается как раз этот вопрос — если в спеке интела сказано что ME/AMT нет, то нет ли его на самом деле, или физически в железе он всё-таки есть, просто не активен. Я, конечно, не стал бы исключать такой вариант, но по-моему эта проблема несколько раздута. Возможность удалённо эксплуатировать громадное количество систем отправив им сетевой пакет, вне зависимости от OS этих систем и даже того, включены ли они — это одно. Теоретическая (на данный момент) возможность взломать текущую OS конкретной системы с целью прошить заточенную под материнку конкретно этой системы нестандартную прошивку, которая активирует "как бы отсутствующий" в железе AMT, с целью его эксплуатировать — это уже перебор, господа! Я уже молчу о том, что такой подход будет "применим" всегда и к любой системе — кто помешает после обновления/удаления ME использовать этот подход чтобы сначала вернуть старую уязвимую прошивку а потом захватить AMT?


В общем, проблема была бы понятнее и нагляднее, если бы вокруг неё было меньше восторженной истерии.

powerman
–1

Безусловно. Тем не менее, чтобы обычное приложение из юзер-спейса как-то достучалось до AMT, эксплуатировало уязвимость и в результате этого ускользнуло из под контроля OS, ему нужно сначала сделать что-то (напр. писать в I/O порты). В этот момент приложение ещё находится под контролем OS, и ему, теоретически, можно помешать — смотря каким образом реализовано взаимодействие с AMT (о чём я и спрашивал, собственно).


В случае удалённой эксплуатации помешать невозможно, потому что пришедший по сети пакет будет сначала обработан AMT, до того как его сможет увидеть OS. А вот в случае локальной эксплуатации, судя по всему, доступ к AMT реализуется через I/O порты, доступ к которым для приложений в юзер-спейсе полностью контролируется OS, так что тот же Grsecurity вполне в состоянии защитить систему.

powerman
–1

Вопросы в комментах на хабре задаются как раз тогда, когда времени и/или желания читать первоисточники нет. Я достаточно сильно интересуюсь безопасностью, но всё же не в такой степени, чтобы разбираться в таких вопросах профессионально — у меня и своя работа есть. Так что в данном случае я интересуюсь как обычный обеспокоенный пользователь этих продуктов: каким конкретно образом происходит доступ к ME на моей системе?


Доступ через I/O порты, похоже, заблокирован Grsecurity.
Прямой доступ через физическую память тоже заблокирован Grsecurity (/dev/mem).
Запись в /dev/cpu/*/msr тоже заблокирована Grsecurity.
Остаётся доступ через сеть, когда IPMI/BMC читают и перехватывают пакеты на уровне сетевой карты ещё до того, как их увидит OS (если OS вообще запущена в этот момент).
Есть ещё какие-то варианты помимо вышеупомянутых?


Что касается варианта с доступом через сетевые пакеты — насколько я понимаю, в десктопных материнках, в которых нет IPMI/BMC, это работать не должно (WakeOnLan я обычно в BIOS отключаю, не знаю, имеет ли это отношение к данной ситуации).


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

Вот, собственно, то, что мне интересно: работает ли вышеупомянутый "локальный" способ эксплуатации при наличии Grsecurity, и если работает — то через что. Раз возможности удалённо эксплуатировать вроде бы нет, то не похоже, чтобы отправка/инжектирование специально сформированного сетевого пакета давала доступ к ME. А все остальные локальные способы вроде бы заблокированы Grsecurity.

powerman
0

Безусловно, но ведь до ME сначала надо как-то добраться. И вот добраться до ME grsec помешал.

powerman
0

Там есть ссылка на тулзу intelmetool, которая должна показать текущее состояние ME. Я попробовал у себя запустить, но ничего не вышло:


kern.alert: grsec: denied use of iopl() by /home/powerman/tmp/coreboot/util/intelmetool/intelmetool[intelmetool:12327] uid/euid:0/0 gid/egid:0/0, parent /bin/zsh[zsh:12020] uid/euid:0/0 gid/egid:0/0

Надо полагать, наличие Grsecurity в ядре помешает не только этой тулзе, но и попыткам эксплуатировать ME…?

powerman
0

У меня SSD нет, так что дисковый кеш я оставлю в покое. С ним:


% time zsh -f -i -c 'autoload -Uz compinit ; compinit -D'
0.113 real  0.086 user  0.024 sys  6MB RAM

% rm -f ~/.zcompdump*
% time zsh -f -i -c 'autoload -Uz compinit ; compinit'
0.167 real  0.132 user  0.029 sys  6MB RAM
% time zsh -f -i -c 'autoload -Uz compinit ; compinit'
0.026 real  0.018 user  0.007 sys  6MB RAM

% time zsh -f -i -c 'autoload -Uz compinit ; compinit -C'
0.021 real  0.020 user  0.000 sys  6MB RAM

Но ведь кеш compinit можно ещё и откомпилировать, как я упоминал выше!


% zcompile ~/.zcompdump
% time zsh -f -i -c 'autoload -Uz compinit ; compinit'
0.011 real  0.005 user  0.006 sys  6MB RAM
% time zsh -f -i -c 'autoload -Uz compinit ; compinit -C'
0.004 real  0.004 user  0.000 sys  6MB RAM

Вооот! Такие цифры мне нравятся намного больше. Хотя -C в реальной жизни использовать вряд ли получится, вручную за актуальностью следить как-то не хочется.


Update: Размеры:


-rw-r--r-- 1 powerman powerman 40264 апр 25 22:41 .zcompdump
-r--r--r-- 1 powerman powerman 88728 апр 25 22:43 .zcompdump.zwc
powerman
0

Что даёт compinit написано в man zshcompsys. Если всё работает — вероятно ваш фреймворк тоже вызывает compinit (они все это делают, что характерно) и ничего не потеряно.

powerman
0
100 мс — пустой .zshrc

Так не должно быть. Пустой это вот так:


% time zsh -f -i -c 'echo ok'                                                                  
ok

0.002 real  0.001 user  0.000 sys  8MB RAM

Система у меня чуть по-быстрее Вашей (i7 @ 4.5GHz, hdd, zsh-5.2, gentoo), но не настолько же.

powerman
0

zwc удалять не надо, их надо создавать (хотя может и не для всего — для совсем мелких файлов у меня есть подозрение, что zwc только тормозов добавляют).


Конфиг мой можно будет увидеть чуть позже, когда я закончу его допиливать и выложу на гитхаб как dotfiles.


Для скорости выполнения .zshrc я использую следующие подходы:


  • не загружать ненужные плагины (банально, да)
  • стараться запускать как можно меньше внешних команд $(cmd args …) или хотя бы отложить их запуск до момента, когда они реально понадобятся при запуске какой-то команды ручками
  • если какая-то функция/плагин при загрузке делает сложные расчёты/заполнение больших массовов/хешей (напр. коды для 256 цветов) — скидываю уже заполненный массив/хеш в кеш-файл и при следующей загрузке этой функции/плагина читаю из кеша (при условии, что файл кеша новее файла самой функции/плагина)
  • подгружаю плагины через свою функцию zsource
  • вызываю свою функцию zzcompile для:
    • файла с кешем completions (.zcompdump) — кеш это хорошо, а хорошо откомпилированный кеш это ещё лучше :)
    • самого .zshrc — он у меня пока довольно большой т.к. по сути заменяет фреймворк
    • дополнительных файлов крупных плагинов (вроде fast-syntax-highlighting/fast-highlight) которым фреймворк автоматически не делает zcompile

zsource:


# Ensure sourced file will be loaded faster… at least next time.
source $1
zzcompile $1

zzcompile:


# (Re-)Compile source files in background, if needed.
[[ $1.zwc -nt $1 ]] || {
    sleep 1         # looks like mtime difference must be > 1 sec, or .zwc will be ignored
    zcompile -U $1
} &!

пример использования:


autoload -Uz compinit
compinit -d $ZSH_CACHE_DIR/zcompdump
zzcompile $ZSH_CACHE_DIR/zcompdump
...
zsource $BUNDLE/dircycle/*.plugin.zsh
zsource $BUNDLE/fast-syntax-highlighting/*.plugin.zsh
...
zzcompile $ZDOTDIR/.zshrc
zzcompile $BUNDLE/fast-syntax-highlighting/fast-highlight
powerman
+1
с парой секунд ожидания на старте мы готовы мириться.

Если Вы про время старта zsh, то это, вообще-то, проблема решаемая. Я лично не люблю автоматическое обновление плагинов, ни для vim, ни тем более для шелла (помимо прочего, это ещё и немаленькая дыра в безопасности) — я лучше буду делать плагинам git pull когда мне это нужно, ещё и посмотрев при этом git diff. А вот скорость работы я люблю, включая скорость запуска (у меня постоянно запущено под 20 терминалов, и все они автоматом запускаются при загрузке компа).


Если выкинуть сложную и медленную логику обновления разных типов плагинов, то всё остальное можно заоптимизировать при желании на пару порядков относительно "самого быстрого фреймворка":


% time zsh -i -c 'echo ok'
ok

0.037 real  0.025 user  0.009 sys  8MB RAM

Это скорость запуска весьма навороченного конфига (там только моего кода около 1000 строк, плюс кучка плагинов — zsh-completions, syntax highlighting, частично грузится oh-my-zsh, ну и разная мелочь в количествах).

powerman
0

Об этом упомянуто и в статье и в комментах, но при желании это делается и для bash (точнее, для urxvt — плагин confirm-paste плюс http://lists.schmorp.de/pipermail/rxvt-unicode/2017q1/002360.html).

powerman
0

Для выполнимых файлов — безусловно. Но на каталоге setgid чем плох?

powerman
0

Всё верно. :(


Теоретически, можно дать доступ ко всем нужным файлам приложения через права группы и setgid-каталоги, поставить всем umask 0002, тогда через sudo под аккаунтом самого приложения надо будет исключительно его запускать/перезапускать, а работать можно под личным аккаунтом.


Но при попытке применять этот подход на практике постоянно вылезали какие-то шероховатости. Нередко попадаются не очень качественно написанные приложения и скрипты, которые нечаянно удаляют setgid-бит каталогам когда пытаются изменить их права. Или, зачем-то, игнорируют umask и форсируют "безопасные" права. Плюс, имея полный доступ к файлам приложения его возможно запустить под личным аккаунтом, и очень часто по ошибке это и делали. А потом другой юзер не мог прибить процесс чтобы его перезапустить. Последнее, вероятно, проблема решаемая — можно в стартовом скрипте приложения проверять $UID, например, но количество излишних сложностей и потенциальных проблем начинает превышать комфортный уровень, в результате чего все на это забивают и продолжают пользоваться общим аккаунтом.

powerman
0

Поэтому я и написал "… подчитать смогут все, так или иначе". Можно оставить основным шеллом bash или даже sh, просто написать в ~/.bashrc exec fish/tcsh, чтобы они запустились уже с этими переменными, можно загрузить в них эти переменные кучей других способов. Об этом не должна болеть голова при основном администрировании сервера, это вполне может быть личной проблемой тех, кому нужен fish/tcsh — главное, чтобы для них эта проблема была решаемой в принципе.

powerman
+1

Мой практический опыт сводится к тому, чтобы во-первых избегать использования общих админских аккаунтов, и во-вторых стараться на сервера вообще ручками ходить по-реже и делать там по-меньше, а не к тому, чтобы на любом из 1000 серверов было удобно работать в zsh через sudo (в этом плане, кстати, когда на серверах работать неудобно — это скорее плюс, лишний мотив этого избегать в принципе). Удобно работать должно быть на рабочей станции и на 2-3 уникальных серверах, которые админятся по-старинке ручками, а не через ансибл.


Но мы вроде не мой личный практический опыт обсуждали, а принципиальную возможность и смысл установки zsh на сервера, причём по умолчанию, из коробки. На мой взгляд ничего утопичного в том, чтобы не использовать общий аккаунт для администрирования и в том, чтобы поставить везде пакет zsh — нет. Насколько это нужно реальным юзерам — посмотрите на результаты голосования, даже учитывая что статья про zsh они довольно показательны.

powerman
0

Угу. Только свои комменты. Именно. У нас здесь вообще-то есть определённый контекст, и обсуждаем мы не SAP. Какое отношение описанное Вами имеет к сложности/неприемлемости установки zsh на 1000 разношёрстных серверов в энтерпрайзе?

powerman
0
Категоричность обычно не является профессионализмом.

Звучит немного категорично, нет? :)


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


А если заведется любитель fish или ipython или tcsh? :)

Переменные окружения заданные в формате posix sh подчитать смогут все, так или иначе. Суть ведь не в том, чтобы сделать удобно всем сразу, а в том, чтобы дать возможность желающим сделать себе удобно самостоятельно.

powerman
0

Общие паттерны здесь не при чём. Хотя они всё-равно всегда есть, просто относятся к инфраструктуре, а не основной задаче сервера: логи, бэкапы, обновления, добавление аккаунтов для новых сотрудников, etc. И если сервер умер или его надо обновить/переустановить — Вы предпочтёте разыскивать уволившегося два года назад сотрудника, который знал что/как/почему надо настраивать на этом сервере, или всё-таки запустить плейбук ансибла который тупо раскатает на новый сервер всё, что необходимо — пусть даже этот плейбук нужно было когда-то написать конкретно для этого сервера?

powerman
–1

Особый общий ENV большинству команд не требуется, но в любом случае это не проблема — если он "общий", то какая разница, поддерживать его в /root/.bashrc или в /etc/profile.d/?
Notes в виде файла на конкретном сервере? Вы так шутите? Ну или это было очень-очень много лет назад. Сейчас для этой цели есть wiki.
Скрипты для bash/zsh/ansible — на то и скрипты, чтобы их можно было запускать всем, вне зависимости от того, какой у кого $SHELL.


реальный опыт организации работы в компании, которая занимается поддрежкой очень крупных и дорогих клиентов

Во-во. Типичные условия развития махрового консерватизма, когда всё делается по принципу "так было всегда" и "ничего не менять пока мы из-за этого не теряем деньги". К здравому смыслу и эффективной работе всё это отношения не имеет.

powerman
0
Админ редко один, поэтому нужно находить компромис с коллегами.

Просто не надо использовать общие аккаунты и sudo -i. Если каждый админ использует личный аккаунт и sudo для индивидуальных команд — ему ничего не мешает иметь личный ~/.zshrc. Помимо прочего это намного более здраво в плане безопасности, аудита и контроля доступа отдельных сотрудников.

powerman
+2
… в реальном использовании bash … не настолько менее продуктивен, чтобы ради этого переходить …

С этим я соглашусь. Но это не значит, что переходить нет смысла. Переход на zsh — вопрос не продуктивности, а удобства. И даже если через год вернуться на bash, то оно всё-равно того стоит, потому что вернётесь Вы уже с пониманием, что и как можно сделать удобнее лично для Вас, и часть этого действительно получится реализовать в bash — так что время потраченное на изучение и использование zsh не пройдёт даром (потому что в результате Вам станет удобнее работать в bash).


Вообще, bash штука странная. Умение писать на нём скрипты — является скорее минусом, потому что как только эти скрипты выходят за пределы лично ваших компов, то вас (почти) сразу начинают тыкать носом в "башизмы" в этих скриптах и просить переписать их так, чтобы они работали на любом sh (мне пришлось даже тулзу checkbashisms поставить для упрощения этого процесса). То, что bash "везде установлен" — вообще-то не является правдой, в BSD его обычно из коробки нет, в некоторых линухах вроде OpenWRT тоже нет, etc. А то, что его обычно первым делом устанавливают — ну так ровно с тем же успехом можно было и zsh поставить. Но даже если bash из коробки есть, то вот пакет bash-completion уж точно из коробки отсутствует — а Вы вроде не отрицаете реальную необходимость автодополнения для bash. И снова, в чём принципиальная разница между необходимостью на каждой системе первым делом ставить пакет bash-completion или пакет zsh? То, что "bash везде одинаковый" — тоже не правда, потому что тогда Вам нужно перестать использовать все alias-ы и дополнительные keybinding-и в inputrc. "Голый" bash, без алиасов в .bashrc, без автодополнений и keybinding-ов, который есть почти но всё-равно не везде — это действительно то, чем Вы бы хотели ежедневно пользоваться? И чего ради, чтобы не устанавливать ни одного лишнего пакета, который не нужен для выполнения основных функций сервера?


На мой взгляд в отношении bash/zsh основная проблема скорее в инерции мышления и консерватизме, нежели в реальных причинах предпочитать bash. Примерно так, как было когда-то, когда сайты дизайнили "под IE" а не по стандартам, потому что "IE есть у всех". Там ситуацию, хоть и с громадным трудом, переломили — потому что были заинтересованные в этом крупные игроки. А в отношении bash/zsh таких нет, если мы хотим чтобы нам же было удобнее, то менять ситуацию (читай — ставить везде zsh по умолчанию, просто из вежливости к коллегам) надо нам самим.

powerman
+1

Реальной необходимости нет в абсолютном большинстве нововведений. Любая ОС 15-ти летней давности содержит всё реально необходимое для работы. Даже в хабре нет реальной необходимости для работы "большинства матёрых линуксоидов"… но, тем не менее, Вы зачем-то тут читаете статьи и даже комментируете (а была ли реальная необходимость в Вашем комментарии?). Что касается "красивостей" — то же можно сказать и про абсолютное большинство книг/фильмов/картин/музыки — реальной необходимости в них нет. (Кстати говоря, если говорить абсолютно честно и искренне, не принимая во внимание желание оправдать получаемую зарплату — а есть ли реальная необходимость в большей части Вашей работы? Вы действительно каждый день делаете то, без чего нельзя обойтись, ваши проекты и сервера действительно реально необходимы человечеству?)


Суть в том, что нет реальной необходимости ограничивать себя реально необходимым минимумом, если можно сделать красивее, удобнее, интереснее… Иногда это вредит продуктивности, иногда помогает, но продуктивность — в любом случае не самое главное в жизни.


P.S. Что касается "я матёрый линуксоид, знаю все нужные флаги" — когда на глаза регулярно попадается список флагов при автодополнении, то даже матёрому линуксоиду это позволяет регулярно открывать для себя новые флаги и возможности, без которых можно было бы обойтись, конечно, но которые могут быть полезны/удобны. Я вот полностью список флагов ls и многих других базовых команд первый и последний раз читал примерно в 1994, когда осваивал линух. После этого у меня всегда было чем заняться и без перечитывания этих man-ов в поисках "а нет ли там чего полезного, чего не было в 1994 либо что я в 1994 не оценил/не запомнил".

powerman
0

Подключить плагин dircycle из oh-my-zsh.

powerman
0

Попробуйте это (возможно стоит указать только local-directories, а остальное выкинуть):


zstyle ':completion:*:*:-command-:*:*' group-order \
    local-directories directory-stack named-directories directories
powerman
0

А при запуске zsh -f этот эффект тоже наблюдается?
Если нет — проблема в Ваших конфигах zsh, или в ~/ или в /etc/.
Если да — возможно проблема в каких-то общесистемных вещах, но для начала стоит попробовать обновить zsh на 5.2 или более новую версию.

powerman
0

А можно чуть конкретнее? Что именно тормозит и как Вы это определяете?

powerman
+1
на моем ноуте zsh тормозит конкретно.

Это не zsh. В самом zsh тормозить нечему. Это тормозила чужая навороченная конфигурация с кучей включённых по умолчанию плюшек (вроде oh-my-zsh), которую Вы, вероятно, поставили, чтобы получить "вау-эффект" с первой минуты.

powerman
0

С вариантом на terminfo есть свои проблемы (конкретно в моём случае).
Во-первых, я начитался про то, как у людей подтормаживает zsh при запуске из-за большого количества подключённых модулей/плагинов, поэтому стараюсь изначально не подгружать то, без чего можно обойтись.
Во-вторых, в $terminfo есть далеко не все кнопки, например как через него получить код для Ctrl-PageUp?
В-третьих, у меня в ~/.Xresources есть немаленький блок строчек URxvt.keysym.* задающий конкретные escape-последовательности конкретным кнопкам (без этого часть комбинаций не работает в Vim)… и что-то я сомневаюсь, что $terminfo будет возвращать именно эти комбинации, это было-бы как-то уж слишком волшебно.
Ну и в последних — у меня не так много разнотипных серверов, везде примерно одно и то же, так что файл с результатом zkbd попадёт на сервера вместе с остальными конфигами zsh и будет, я полагаю, вполне корректно работать везде, без необходимости вызывать zkbd на каждом сервере отдельно.

powerman
0

Удобство создаётся не какой-то киллер-фичей, а множеством разных мелочей.


Лучше на дефолте, но зато везде одинаково, чем тут zsh, а везде bash и ругайся потом, что чего-то работает не так, как ты привык. Пожалуй это главный аргумент в пользу оставить всё как было.

Я про это отписался выше: настройте zsh опциями так, чтобы максимально эмулировать поведение bash, забудьте про одну-две фичи zsh которые могут создать проблемы в bash — и вы получите большую часть доступных удобств zsh без создания себе проблем при наборе привычных по zsh команд в bash.

powerman
0
Я не пытался сделать какие-то претензии к zsh, я просто хочу показать, что его функционал излишен для выполнения работ на удаленных машинах в целях системного администрирования.

Хм. А почему Вы для таких работ используете bash, ведь есть же sh? Разве функционал bash не излишен примерно в той же степени, что и zsh?


Догадываетесь почему? Потому что это нафиг никому не надо — смотреть в непонятный пестрый экран.

Звучит как "виноград кислый", если честно. Я, лично для себя, пока ещё не определился, нравится мне подсветка синтаксиса или нет (но скорее всего надо просто немного поднастроить цвета, может отключить подсветку отдельных элементов). Но я не вижу абсолютно никакой проблемы в том, что при наборе на удалённом сервере я сразу вижу есть ли опечатка в имени команды или не закрытые кавычки, ещё в процессе набора, до запуска команды. Если оно из коробки "пёстрое" — ну так подправьте цвета под свой вкус, отключите подсветку лишних элементов, но в самой идее подсветки синтаксиса абсолютно ничего плохого нет, и продуктивность это обычно повышает.


Люди используют удаленные сессии, как там вообще может удаленный zsh перехватывать буфер обмена?

Хрен его знает. :) Но я только что проверил — через ssh работает, а в screen (даже локальном) — нет.


Не хочется. Для этого я запущу find или xargs, а в самом сложном варианте сделаю через однострочних в цикле for.

А мне вот хочется. Вероятно, это дело вкуса. Я линух админю уже 23 года, но параметры find для меня так и не стали интуитивно понятными, что-то чуть нетривиальное — приходится сначала лезть в man, а потом ещё и экспериментировать немного, чтобы убедиться что команда возвращает нужные файлы. Так что возможность использовать find значительно реже — для меня выглядит довольно привлекательно.


вот попробуйте испоьзовать этот прием на рабочем сервере с миллионом (или сколько там ограничение у разных fs) файлов. Вы в таких случаях отучитесь вообще пробовать у шелла автодополнение. Попробовать такое на embedded дистрибутивах также вам доставит удовольствие.

Практически всё, что даёт удобный интерфейс и облегчает жизнь пользователя — делает это за счёт большего количества вычислений, т.е. потерь производительности. Обычно это не заметно, потому что время реакции человека меньше этих задержек. Но, да, бывают крайние случаи когда это заметно. И если Вы 90% своего времени выполняете команды в каталоге с миллионом файлов или на невероятно медленном устройстве — zsh тут действительно будет неуместна. Но, как правило, 90% своего времени проводится вовсе не в таких условиях, и проще быть осторожнее в набираемых командах когда изредка оказываешься в таких условиях, чем лишать себя удобств во всё остальное время.


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

Дополнять надо всё. Во-первых потому, что это проще и быстрее, но важнее то, что это мешает делать опечатки.


Просто каждому хотелось бы, чтобы write-only рецепт сработал как на нагруженном сервере, так и на очередной поделке с dd-wrt, так и на локальной машине.

Да. К сожалению, мир устроен иначе. Я вот изредка попадаю на сервера где нет bash. И половина набираемых мной команд, внезапно, перестаёт работать как ожидалось. Знаете, что я в этот момент делаю? Устанавливаю, с матами, bash. А ещё bash бывает разных версий, так что часть привычных конструкций изредка на древних серверах выдаёт не то, что ожидается (такое бывает не часто, да, но всё-равно). Так что Ваша мечта всегда будет только мечтой, к сожалению.


А учить для одного сервера zsh, для того, чтобы на сотне других пользоваться bash, как-то уже совсем не то.

Вот! Именно это и удерживало меня от изучения zsh долгие годы. И именно про это написана статья — чтобы показать, что отличий между bash и zsh не так много, что "учить zsh" это не так масштабно и сложно как кажется на первый взгляд, что практически все команды которые работают в bash будут ровно так же работать в zsh (а если включить SH_WORD_SPLIT — тогда, думаю, вообще все в которых не встречается $BASH…).


Запомнить что в bash нельзя пользоваться флагами/квалификаторами/модификаторами несложно, и даже если что-то такое набрать по привычке случайно в bash — будет не трагедия, а синтаксическая ошибка (как и для сокращённых вариантов if|while|for). Автодополнение в bash будет работать хуже, но это тоже не помешает набирать корректные команды. По большому счёту, основное что может создать проблему помимо SH_WORD_SPLIT — это шаблоны с <число1-число2>, которые bash скорее всего поймёт как перенаправление stdin/stdout.


Если нужно много работать с bash, то Вам никто не мешает включить SH_WORD_SPLIT и забыть про возможность использовать <число1-число2> в шаблонах. Тогда шанс, что привычная по zsh команда некорректно заработает в bash, будет пренебрежимо мал. В общем-то, именно для таких ситуаций в zsh и существуют эти 177 опций, кардинально влияющие на поведение и поддерживаемый синтаксис — чтобы каждый мог работать в такой zsh, которая подходит лично ему, а не в такой же zsh, как у всех.


Наверно, zsh хорошо подходит, если много работаешь именно на локальной машине.

Да. Но, в идеале, на серверах вообще нежелательно ручками работать, для этого есть ansible/chef/etc. Идеал не всегда достижим, конечно, но общая тенденция идёт в этом направлении. Приложения расползаются по docker-контейнерам, в которых вообще не то, что bash, но даже и sh может не быть (хотя бы из соображений безопасности).


Но перекрыть его возможности обычным башем также с легкостью можно.

Это прямая ложь, нехорошо, однако.


я с ним плотно игрался в 2008-2009 (припоминаю, там еще были косяки по unicode)

Да, судя по changelog — было такое. Но сейчас вроде всё ок, так почему наличие багов 8 лет назад является проблемой сейчас?


За все это время с развитием технологий виртуализации, автоматической настройки серверов, я не встречал ни одной крупной организации, где бы в init скриптах на создание очередного сервера стояла автоматическая установка zsh. Я полагаю, это не просто так.

Как я уже выше упоминал, чем дальше мы идём по тропинке виртуализации, увеличения количества серверов и сужения выполняемых ими задач — тем меньше смысла выполнять на этих серверах команды вручную по ssh, они должны управляться через ansible etc. Поэтому там и bash нередко избыточен, не говоря уже про zsh. Так что да, это не просто так.


Shell должен работать быстро везде (за исключением машин в Австралии или подключенных через спутниковый канал=), если появляется лишняя непредсказуемая задержка — она уже сама наводит панику, что какую-то команду я ввел зря.

Угу. Но я пока от zsh задержек не наблюдал. Допускаю, что они бывают, вот эта настройка в oh-my-zsh наводит на такую мысль (но здесь подразумевается индикация причины задержки, так что всё вроде ок):


# Uncomment the following line to display red dots whilst waiting for completion.
COMPLETION_WAITING_DOTS="true"
powerman
+2

Для подсветки разными цветами последовательности действительно отличаются, но: во-первых указанные Вами отвечают не за цвета, а за указание терминалу/screen изменить заголовок окна, а они от шелла не зависят и везде будут одинаковые, а во-вторых в bash даже для смены цвета обычно задаются стандартные последовательности, которые не так удобно читать как "%B%F{red}жирный красный%f%b" в синтаксисе zsh, но зато, опять же, они должны работать одинаково в любом шелле, так что если нет желания переписывать их в синтаксисе zsh — их можно просто скопировать как есть.

powerman
0

И что? Такой bash/sh синтаксис zsh понимает и так, у него очень сильная совместимость с другими шеллами. А вот если вы привыкнете в zsh писать в сокращённой форме:


for i in *.jpg; convert -resize 200x200 $i /tmp/res/`basename $i`.png
# или даже
for i in *.jpg; convert -resize 200x200 $i /tmp/res/${i:t}.png

то всё, что вам грозит при попытке запустить это в bash:


-bash: syntax error near unexpected token `convert'

В общем, если честно, я не вижу трагедии. Ладно шелл, но вот пользоваться на других машинах редактором-убожеством вроде mcedit, nano или не настроенного vim — я "пас" в любом случае. А раз всё-равно приходится везде носить свои настройки для vim, то добавить к ним ещё и настройки для zsh — не сложно.