В опубликованном (http://blog.npmjs.org/post/171139955345/v570) вчера выпуске пакетного менеджера NPM 5.7.0 выявлена (https://github.com/npm/npm/issues/19883) серьёзная проблема, которая может привести к нарушению нормальной работы компонентов операционной системы. При запуске npm с использованием утилиты sudo (не важно, какая команда выполняется, достаточно (https://twitter.com/kennwhite/status/966667121345421312) запустить "sudo npm --help" или "npm update -g") рекурсивно меняются права доступа на каталоги, относительно корневого префикса npm. Судя по отчётам пострадавших пользователей, после подобного изменения могут возникнуть проблемы с загрузкой системы и работой локальных приложений.При запуске вместо root в качестве владельца для системных каталогов, включая всё содержимое /etc, /usr и /boot, устанавливается текущий пользователь. В версии 5.7.0 был осуществлён переход (https://github.com/npm/npm/commit/74e149da6efe6ed89477faa81f...) на новую реализацию mkdir, сохраняющую исходные права доступа и владельца при запуске из-под root. Проблема проявляется только при запуске npm с использованием утилиты sudo и вызвана тем, что в качестве владельца для каталогов определяется пользователь, вызвавший sudo, а не текущий эффективный идентификатор пользователя.
Проблема уже
решена (http://blog.npmjs.org/post/171169301000/v571) в обновлении 5.7.1. Массовых проблем удалось избежать благодаря тому, что в репозитории выпуски npm 5.7.x были помечены (https://github.com/npm/npm/releases) как экспериментальные и не доставлялись через каналы обновления стабильных релизов. При этом на сайте анонс был опубликован (http://blog.npmjs.org/post/171139955345/v570) в форме, не отличающейся от объявлений стабильных релизов, что ввело в заблуждение некоторых пользователей, которые попытались перевести на RPM 5.7 свои рабочие системы. Также интересно, что сообщение об ошибке с описанием проблемы было отправлено (https://github.com/npm/npm/issues/19829) за неделю до релиза 5.7.0, но оставлено без внимания разработчиков.
В случае отсутствия резервной копии для восстановления всех изначальных прав доступа может потребоваться переустановка системы или восстановление прав на уровне пакетного менеджера с ручной корректировкой каталогов пользователей. Например, для систем на базе RPM и DEB можно выполнить:for p in $(rpm -qa); do rpm --setperms $p; do rpm --setugids $p; done
dpkg --get-selections | grep install | grep -v deinstall | cut -f1 | xargs apt-get --reinstall -y --force-yes install
URL: http://blog.npmjs.org/post/171169301000/v571
Новость: http://www.opennet.me/opennews/art.shtml?num=48125
Почему не православный Yarn? npm кто-то еще используем в вменяемом состоянии?
Ярн тоже баги выдаёт, правда не такие лютые
> Ярн тоже баги выдаёт, правда не такие лютыеМожно подумать вебмакаки перестанут быть вебмакаками и научатся софт писать нормально, а не так как они обычно кодят для своей клиентуры.
там речь про -g, который в yarn вообще выпилили
потому что вместо него есть ключевое слово global
Который, однако, не лезет в систему, а складывает всё в домике пользователя.
https://yarnpkg.com/en/docs/migrating-from-npm#toc-cli-comma...
Да. Потому что лень мигрировать и объяснять всем, что поменялось и что теперь запускать.Хотя надо бы.
Впервые попробовать решил для установки фреймворка Semantic UI. Не шмогло.
Что-то я давно его не видел, так что побуду за него, кхм.. node js не нужен, вспомнити npm left pad
Он говорил вообще жс не нужен, вроде.
К слову, чтобы не запускать npm с рут правами:
mkdir ~/.node
echo 'prefix = ~/.node ' >> ~/.npmrc
echo 'export NPM_PACKAGES="$HOME/.node"' >> ~/.bashrc
echo 'export PATH="$NPM_PACKAGES/bin:${PATH}"' >> ~/.bashrc
echo 'export NODE_PATH="$NPM_PACKAGES/lib/node_modules"' >> ~/.bashrc
echo 'unset MANPATH' >> ~/.bashrc
echo 'export MANPATH="$NODE_PARENT/share/man:$(manpath)"' >> ~/.bashrc
Bash/ZSH - фу
NPM - фу
env export - фэ
batfile рулез, да. echo %~dp0
> unset MANPATH
> export MANPATH=...Интересно, и многие вот так скопипастят, даже не задумавшись о том, что первая строчка вообще ни к чему...
>> unset MANPATH
>> export MANPATH=...
> Интересно, и многие вот так скопипастят, даже не задумавшись о том, что
> первая строчка вообще ни к чему...Зависит от того что будет делать $(manpath), очевидно втч читать $MANPATH
> echo 'unset MANPATH' >> ~/.bashrc
> echo 'export MANPATH="$NODE_PARENT/share/man:$(manpath)"' >> ~/.bashrc
Ну тут всё-таки стоило объяснить подробней, что manpath в случае непустой переменной MANPATH просто вернет ее значение, а в случае пустой выдаст дефолтный путь. Хотя зачем это делается в этом скрипте для меня загадка, ведь это может испортить добавления в MANPATH от других секций .bashrc. Какой-то мелкомягкий подход у этих нодовцев.
$ manpathЧто за manpath?
bash: manpath: command not found
В debian и rhel дистрах идет в составе пакета man-db вместе с собственно man, а также apropos, whatis, mandb и другими утилитами. То бишь отсутствует лишь в урезанных установках. Как в других дистрах, не знаю.
Тю, обычная практика. Так во многих конфигах делают: сначала все разбиндить, а потом уже свое.
Копипастить не думая? Да, это обычная практика дурачков. Они ведь даже не пытаются вникнуть в причины и не понимают разницу между разбиндить ВСЁ одной командой и сбросить один параметр с последующим присвоением ему нового значения.
Миша, ну от кого, так от тебя такой хни не ожидал. :-DНаивно полагать что кто-то за тебя очистил стек/кусок памяти/инициализировал переменную с пустым/нулевым значением. Не важно сейчас о каком языке программирования/какой оболочке/командном интерпретаторе/конкретной_блджад_реализации_export идёт речь. Очищать/обнулять/разбиндивать только что созданную переменную нужно ВСЕГДА. Равно как и проверять, что за х..ня в действительности в переменных.
Конкретно в данном случае я бы ещё проверил $NODE_PARENT на наличие перевода строки (и ещё какую-нибудь аномальную хрень, типа кавычек точки-с-запятой и.т.п), потому что идёт запись в файл, где это можно нестандартно использовать ;-).
Равно как и убирать за собой, после того как переменная выполнила задачу. Не надеясь, что волшебные уборщики всё сделают сами. Никогда.Пускай даже код будет где-то избыточен, но следование этим правилам позволит минимизировать уязвимости и улучшить качество ПО.
P.S. Но я бы порекомендовал всем совсем не использовать ни NPM ни Node.js. Без объяснения причин. Без смайлов.
> Но я бы порекомендовал всем совсем не использовать ни NPM ни Node.js. Без объяснения причин. Без смайлов.А что взамен? (тоже серьёзно спрашиваю)
>> Но я бы порекомендовал всем совсем не использовать ни NPM ни Node.js. Без объяснения причин. Без смайлов.
> А что взамен? (тоже серьёзно спрашиваю)Для управления пакетами вполне хватит системы управления пакетами того дистрибутива, который вы используете.
>>> Но я бы порекомендовал всем совсем не использовать ни NPM ни Node.js. Без объяснения причин. Без смайлов.
>> А что взамен? (тоже серьёзно спрашиваю)
> Для управления пакетами вполне хватит системы управления пакетами того дистрибутива, который
> вы используете.У drupal, кстати, тоже есть свой менеджер модулей и тем. Но обновлять теже модули через родные системы управления в разы удобней и эффективней, особенно когда таких хостов дофига и модулей по 30-50 штук.
P.S. Частный случай, для тех кто ещё не въехал.
> Наивно полагать что кто-то за тебя очистил стек/кусок памяти/инициализировал переменную
> с пустым/нулевым значением. Не важно сейчас о каком языке программирования/какой оболочке/командном интерпретаторе/конкретной_блджад_реализации_export идёт речь.Очень даже важно. Например в Go инициализация пустым значением при создании переменной явлется частью спецификации. И если ты будешь в коде на golang заниматься этим, то читатели кода вполне справедливо назовут тебя чудаком на букву "м".
> Очищать/обнулять/разбиндивать только что созданную переменную нужно ВСЕГДА.
Думать желательно всегда. А тупо следовать правилам без их понимания это не очень хорошая идея. Переменную в данном случае не создавали и эксклюзивного права на нее у писашего этот "код" нет.
> Пускай даже код будет где-то избыточен, но следование этим правилам позволит минимизировать уязвимости и улучшить качество ПО.
Конкретно в этом случае следование идиотскому правилу приведет к тому, что будет похерены добавления в MANPATH путей из предыдущих секций .bashrc. Это нечто противоположное улучшению качества.
> P.S. Но я бы порекомендовал всем совсем не использовать ни NPM ни Node.js. Без объяснения причин. Без смайлов.
Действительно, зачем думать, обосновывать, надо тупо следовать.
> Действительно, зачем думать, обосновывать, надо тупо следовать.Если подумать, NPM и все для чего он нужен - одно большое минное поле. Кто ж виноват что вебмакаки и безопасность несовместимы? Вебмакаки умеют только думать как сделать проще. Но потом оказывается что хижину из соломы может сдуть первый попавшийся волк.
/me махнул рукой...Да, делайте как хотите...
Хаскела на Вас нет...
Сколько лет уже скрипты пишу, bash, dash, sh перезаписывают уже существующее значение, так что Михаил прав, нунужные итерации.
> echo 'unset MANPATH' >> ~/.bashrcА вы смелый! вы забыли еще rm rf...
> К слову, чтобы не запускать npm с рут правами:
> ... <много телодвижений> ...Для этого уже давно есть NVM. С ним и рута не нужно, и всё хранится в одной папке, и можно иметь разные версии Node/NPM параллельно.
https://github.com/creationix/nvm
Что не отменяет того, конечно, что экосистемя Node.js для како-кодеров, и нормальный архитектор никогда не примет её (если только ему не нужен хинди-код за хинди-цену в проекте, конечно).
Эк издевательски-то очередную кривулину назвали: correct-mkdir.js.И вот всё у них в песочнице так :-/
осталось блокчейн к этому всему прикрутить и совсем казуально будет.
Поедемте на гироскутерах, отвеадаем смузи в барбершопе, дружище.
> Поедемте на гироскутерах, отвеадаем смузи в барбершопе, дружище.-1
не раскрыта тем барбершопофф
Традиционные факапы npm не прекращают удивлять))
Зачем npm install -g вообще нужен? По идее можно же в любую папку вытянуть npm пакет со всеми необходимыми зависимостями?
Это что бы без песочницы уничтожать хостовый сервер ;)
Кто то использует инструменты написаные на ноде, а их нужно устанавливать глобально
Для глобальной установки есть пакетный менеджер. Всё слаку ругили за make install на боевой системе, вроде прошло. Но нет, не прошло, хипстерам обязательно в обход пакетного менеджера что-то поставить нужно. А ещё лучше через curl ...| bash. Так что не понимаю, чем вызвано удивление по поводу случившегося. "Вы занимались любовью не предохраняясь и ожидали, что оттуда выйдет что? Плазма тв?".
Так ведь при sudo и global пакетный манагер не спасёт ибо npm даже системные бинарники может переписывать
> Так ведь при sudo и global пакетный манагер не спасёт ибо npm даже системные бинарники может переписыватьЗачем sudo и global, если есть пакетный менеджер, как раз и нужный для того, чтобы системные бинарники не перезаписывались всеми подряд?
yum install nodejs-somethingвместоnpm install -g somethingслишком длинно? Или не на яваскрипте написано, поэтому не будем им пользоваться?
а вот теперь покажи jshint, gulp, lesscss и bower в твоём yum. в rh7+epel нету, в ubuntu тоже, в homebrew тоже. никто так js-пакеты не пакетирует (и я даже знаю, почему).
Кто-то запускает npm не в контейнере?
страдальцы, которым приходится кодировать код или учиться этому
Какие есть варианты пробросить PATH внутрь контейнера с нодой и тулкитом глобальным?
https://docs.docker.com/engine/reference/builder/#env
https://docs.docker.com/engine/reference/commandline/run/#se...что больше нравится. Или можно костылем через расшареный файл с хоста закидывать и в контейнере читать
Дорогие анонимы, а расскажите чем так плох npm?
Я вот пользуюсь npm и да, некоторые пакеты требуют установки с -g.
Брат жив, ярн - не пробовал, чем он лучше?
npm - стандарт.
> Дорогие анонимы, а расскажите чем так плох npm?
> Я вот пользуюсь npm и да, некоторые пакеты требуют установки с -g.
> Брат жив, ярн - не пробовал, чем он лучше?
> npm - стандарт.ты новость-то читал?
ты npm leftpad-то вспомнил? Вот вначале вспомни npm leftpad, а потом уже спрашивай. Null undefined. 0.1 + 0.2 = 0.30000000000000004.
Ураааа, двоечник вернулся!!!
Вот еще на посмотреть как альтернатива webpack https://parceljs.org
Логично: "Вэб-пак для вэб-макак".
> Вот еще на посмотреть как альтернатива webpack https://parceljs.orgНедостаточно XMRов! Нужно больше кривой хни от вебмакак, милорд!
Почитать комменты опеннета, так всё сплошь суровые барадатые дятьки, пищущие на сях и только на сях )))А кто ж блин npm-модули то пишет? Ёжики?))
> А кто ж блин npm-модули то пишет? Ёжики?))Вэб-макаки.
Кто робко или в тряске жалуется на минусы PHP
пишу на сях и плюсах под убунты и не только за деньгиспрашивайте свои ответы
такие же дeбилы, которые потом это используют.
Хипстопроблемы. Как пишут софт, так и тестируют.
Зачем вообще npm лапает эти директории?
Потому что может.
это какими придурками нужно быть, чтобы спроектировать программу, которая при выполнении пути программы --help меняет права каких-то там директорий?Жаваскриптуны и все им сочувствующие (типа Mozilla) не должны заниматься программированием.