Комментарии 64
Два вопроса: сколько в книге посвящено xargs? Сколько jq?
Если jq не освещена, книга морально устарела.
Если jq не освещена, книга морально устарела.
Знаете, я 17 лет на линуксе на всех машинах, на которых есть моя учетная запись, и мне ни разу не потребовалось хоть что-то сделать с джейсоном.
Зачем такой узкоспецифичной фигне посвящать больше одной строчки?
Зачем такой узкоспецифичной фигне посвящать больше одной строчки?
Дело в том, что это не «узкоспециализированная фигня», а механизм (в настоящий момент — единственный, пока MS не допилит powershell в Линуксе до приличного состояния), который позволяет работать со структурированными данными в шелле.
Ни awk, ни sed, ни другие подручные средства не позволяют уверенно говорить о структуре входных и выходных данных.
То, что лично вы 17 лет ни разу не сталкивались с такого рода задачами, всего лишь говорит о круге задач, которые вы решаете, а не о важности инструмента.
Ни awk, ни sed, ни другие подручные средства не позволяют уверенно говорить о структуре входных и выходных данных.
То, что лично вы 17 лет ни разу не сталкивались с такого рода задачами, всего лишь говорит о круге задач, которые вы решаете, а не о важности инструмента.
> механизм [..] единственный [...] который позволяет работать со структурированными данными в шелле
Во-первых, это не так. Структурируйте данные в CSV и используйте `cut` в свое удовольствие.
Во-вторых, зачем бы это мне работать в шелле со структурированными данными? Я в микроконтроллере, даже без перла? — ну тогда это «узкоспециализированная фигня». Я на нормальном хосте? — ну так я, спасибо, перлом, руби, питоном, юнеймит буду парсить.
Во-первых, это не так. Структурируйте данные в CSV и используйте `cut` в свое удовольствие.
Во-вторых, зачем бы это мне работать в шелле со структурированными данными? Я в микроконтроллере, даже без перла? — ну тогда это «узкоспециализированная фигня». Я на нормальном хосте? — ну так я, спасибо, перлом, руби, питоном, юнеймит буду парсить.
Вы говорите правильные слова, но не учитываете особенностей CSV. В CSV могут быть символы точка с запятой, в кавычках (или эскейпленные, я не помню). Их вырезать cut'ом уже не получится. Ни один существующий формат не работает с шеллом так, чтобы не было edge-case'ов. Только jq и json в настоящий момент позволяют это сделать гарантированно правильно, с учётом синтаксиса формата данных.
Насчёт микроконтроллера — последний раз, когда я был на микроконтроллере, на нём крутился jvm с rest-api. Памяти было маловато (32Мб), но для нужд java хватало.
Если же вы говорите про совсем-совсем embedd, то в нём нет «командной строки линукса», точнее есть — это /proc/cmdline, но у меня есть интуитивное представление, что книжка всё-таки не про linux, а про coreutils/psutls и прочие GNU'шные радости.
Вот в этом контексте я и говорю про важнейший новый инструмент, который обязательно должен быть освещён в профлитературе.
Насчёт микроконтроллера — последний раз, когда я был на микроконтроллере, на нём крутился jvm с rest-api. Памяти было маловато (32Мб), но для нужд java хватало.
Если же вы говорите про совсем-совсем embedd, то в нём нет «командной строки линукса», точнее есть — это /proc/cmdline, но у меня есть интуитивное представление, что книжка всё-таки не про linux, а про coreutils/psutls и прочие GNU'шные радости.
Вот в этом контексте я и говорю про важнейший новый инструмент, который обязательно должен быть освещён в профлитературе.
Давайте я совсем просто, для очень упертых. Вы строите какие-то безумные обобщения, приписываете мне неучет чего-то там, сами себе противоречите.
Если вы можете убедить отсылающую сторону слать json, то и заменить точки с запятой внутри полей на ★ сумеете. Поэтому CSV прекрасно подходит. Надо сложную структуру разворошить? — возьмите перл уже, не нужно мучить зрителей. Наколеночная поделка для непоймичего (вы так и не смогли представить ни единого мало-мальски осмысленного юзкейса, в котором вдруг надо парсить json (!) голым шеллом (!!)) — нахрен никому не вперлась, и отводить ей место в книге, как минимум, странно.
JSON вообще должен сдохнуть, но, к сожалению, я понимаю, что этого в ближайшем будущем не случится.
Если вы можете убедить отсылающую сторону слать json, то и заменить точки с запятой внутри полей на ★ сумеете. Поэтому CSV прекрасно подходит. Надо сложную структуру разворошить? — возьмите перл уже, не нужно мучить зрителей. Наколеночная поделка для непоймичего (вы так и не смогли представить ни единого мало-мальски осмысленного юзкейса, в котором вдруг надо парсить json (!) голым шеллом (!!)) — нахрен никому не вперлась, и отводить ей место в книге, как минимум, странно.
JSON вообще должен сдохнуть, но, к сожалению, я понимаю, что этого в ближайшем будущем не случится.
ОООЛООООокей, вы просто не понимаете, зачем структурированные данные в шелле. если отвечать коротко, то для того, чтобы решить проблему однострочником в 50 символов, вместо программы на перле/питоне в 50 строк.
Ввот вам кусок продакшен-запроса: ceph osd dump -f json|jq ‘.osds[]|select(.osd == 11)|.uuid’
Ввот вам кусок продакшен-запроса: ceph osd dump -f json|jq ‘.osds[]|select(.osd == 11)|.uuid’
Ну ясно, сейчас вы предложите `ceph` тоже включить в книгу «Линукс для начинающих». Я представления не имею, зачем у вас продакшн так устроен, и знать, простите, не желаю.
Во-первых не «для начинающих», а «полное руководство». Во-вторых, я упор делаю не на ceph, а на то, как с использованием jq есть возможность формировать осмысленные запросы по структурированным данным. Это инструментарий одного уровня с sed'ом, но новее. Если книга не освещает jq подробно, то это не полное руководство, а какая-то детсадовская порнография.
> Если книга не освещает jq подробно, то это не полное руководство, а какая-то детсадовская порнография.
Судя по вашей логике, руководство может быть полным только если освещает все существующие на свете утилиты (по крайней мере на момент написания книги).
Т.к. может найтись человек, который использует утилиту, разбирающую формат xml (тоже структурированные данные).
Он тоже скажет: про jq написали, а про xmlq — нет. Значит это не «полное руководство». И т.д.
Книга называется «Полное руководство...» т.к. по мнению автора он осветил все ключевые моменты работы в коммандной строке. Нет смысла придираться к названию.
Судя по вашей логике, руководство может быть полным только если освещает все существующие на свете утилиты (по крайней мере на момент написания книги).
Т.к. может найтись человек, который использует утилиту, разбирающую формат xml (тоже структурированные данные).
Он тоже скажет: про jq написали, а про xmlq — нет. Значит это не «полное руководство». И т.д.
Книга называется «Полное руководство...» т.к. по мнению автора он осветил все ключевые моменты работы в коммандной строке. Нет смысла придираться к названию.
> с использованием jq есть возможность формировать осмысленные запросы по структурированным данным
Форматов структурированных данных уйма. Про каждый рассказывать, места не хватит.
Вам близок формат json, вы о нем говорите. Но книга для широкого круга, поэтому про все форматы придется упомянуть (ну или о 5 самых популярных, например).
Хоть кое-где json используется часто, на самом деле вещь специфическая. A если про каждую специфическую вещь в книге не написать, она станет толстая-претолстая. И найдется мало желающих ее приобрести.
Надо понимать, что есть вещи общеупотребительные и специфические.
Текст — сущность общеупотребительная, про обработку текста в книге немало отведено места.
А json — это текст оформленный специальным образом (по крайней мере в контексте работы в командной строке).
Форматов структурированных данных уйма. Про каждый рассказывать, места не хватит.
Вам близок формат json, вы о нем говорите. Но книга для широкого круга, поэтому про все форматы придется упомянуть (ну или о 5 самых популярных, например).
Хоть кое-где json используется часто, на самом деле вещь специфическая. A если про каждую специфическую вещь в книге не написать, она станет толстая-претолстая. И найдется мало желающих ее приобрести.
Надо понимать, что есть вещи общеупотребительные и специфические.
Текст — сущность общеупотребительная, про обработку текста в книге немало отведено места.
А json — это текст оформленный специальным образом (по крайней мере в контексте работы в командной строке).
Упор не на json, а на работу со структурированными данными. Я не знал, что есть что-то, кроме jq. Оказалось, есть ещё xmlq.
Задам, все-таки, этот вопрос еще разок: зачем обрабатывать структурированные данные шеллом? Кроме «вот вам пример того, как мы извращаемся в продакшене».
А зачем вообще что-то делать в шелле? Ровно за тем же и «структурированные данные». Нужно посмотреть конкретное значение в выводе на ~30 экранов — смотришь. Скриптом, а не выискиваешь руками. Нужно вывести топ по утилизации? Выводишь, etc, etc.
Сверился с календарем: на моем 2016. Я в шелле нахожусь примерно 50% всего времени, которое провожу за компьютером. Но я попрошу об эвтаназии, если замечу за собой анализ 30 экранов map-reduce’ом _в шелле_.
Что такое «топ по утилизации», простите, мне неизвестно.
Но и в том, и в другом случае я либо научу того, кто отдает json на 30 экранов… Хотя нет, этого уже ничему не научить. Ладно, это бессмысленная дискуссия, вы решаете задачи, которых в моем мире не существует из-за того, что я стараюсь продумывать архитектуру. Наверное, судя по существованию утилиты, есть еще миры, в которых такие задачи есть.
Вы считаете, что это нормально, и тогда, безусловно, утилиту нужно упомянуть в книжке. Я считаю, что jq — костыль для решения дичайшей архитектурной проблемы. map-reduce надо делать там, где он является эндемиком. И шелл — точно не такой ареал.
Что такое «топ по утилизации», простите, мне неизвестно.
Но и в том, и в другом случае я либо научу того, кто отдает json на 30 экранов… Хотя нет, этого уже ничему не научить. Ладно, это бессмысленная дискуссия, вы решаете задачи, которых в моем мире не существует из-за того, что я стараюсь продумывать архитектуру. Наверное, судя по существованию утилиты, есть еще миры, в которых такие задачи есть.
Вы считаете, что это нормально, и тогда, безусловно, утилиту нужно упомянуть в книжке. Я считаю, что jq — костыль для решения дичайшей архитектурной проблемы. map-reduce надо делать там, где он является эндемиком. И шелл — точно не такой ареал.
> Упор не на json, а на работу со структурированными данными
Вот здесь как раз вопрос методологии обучения.
Книга учит человека, что можно обрабатывать данные в виде цепочек команд.
Т.е. человек знает, что в командной строке данные могут передаваться от одной программы к другой. И, если, какой-то этап коневеера его не устраивает (например обработка json с помощью awk), он просто ищет замену awk.
А что там передается, как данные обрабатываются — это вопрос не принципиальный в данном случае.
В книги просто приведны примеры для утилит работающих с текстом, как самых широко распространенных.
Вот здесь как раз вопрос методологии обучения.
Книга учит человека, что можно обрабатывать данные в виде цепочек команд.
Т.е. человек знает, что в командной строке данные могут передаваться от одной программы к другой. И, если, какой-то этап коневеера его не устраивает (например обработка json с помощью awk), он просто ищет замену awk.
А что там передается, как данные обрабатываются — это вопрос не принципиальный в данном случае.
В книги просто приведны примеры для утилит работающих с текстом, как самых широко распространенных.
Когда же вы уже сделаете оплату через банковскую карту?
Еще и трусливо отклоняют правдивые комментарии специалистов.
Книга какой-то жесткий привет из прошлого.
netstat который уже 10 лет deprecated(используйте ss и lsof), fdisk который работает с MBR(в то время, как все давно перешли на GPT и нужно описывать parted), передача файлов по ftp(руки отрывать за такие идеи).
И это только беглый взгляд на оглавление. Подозреваю, что внутри будет еще и ifconfig, который тоже депрекейтед и прочие прелести из девяностых.
Книга какой-то жесткий привет из прошлого.
netstat который уже 10 лет deprecated(используйте ss и lsof), fdisk который работает с MBR(в то время, как все давно перешли на GPT и нужно описывать parted), передача файлов по ftp(руки отрывать за такие идеи).
И это только беглый взгляд на оглавление. Подозреваю, что внутри будет еще и ifconfig, который тоже депрекейтед и прочие прелести из девяностых.
Не рекламы ради: посоветуйте, пожалуйтса, литературу/статьи по теме.
Книги никогда не будут поспевать за IT-сферой. Есть книга на все времена, за авторством Эви Немет, которую нужно прочитать для общего ознакомления, а дальше читайте маны и статьи на профильных сайтах.
Хорошо, спасибо :)
Да не за что. Книгу Эви Немет стоит прочитать просто для общего понимания, ну и как исторически важную для книг о Unix и Linux веху. А все прочее нужно читать уже в конкретные моменты.
Собственно вот мои претензии к книге представленной издательством как раз по той причине, что у них материал устарел на 10-15 лет и описывает устаревшие команды(как netstat и fdisk) или устаревшие технологии(как ftp).
Собственно вот мои претензии к книге представленной издательством как раз по той причине, что у них материал устарел на 10-15 лет и описывает устаревшие команды(как netstat и fdisk) или устаревшие технологии(как ftp).
Помогите мне разобраться в вопросе. Я сам по большей части программист, но для моей работы мне необходимо работать с серверами. В моем мире работы с линуксом команда netstat и передача файлов по ftp в принципе случалась и я как-то не задумывался, что это устаревшие технологии. Вот собственно вопрос, что Вы можете предложить взамен этих двух технологий, мне реально интересно?
> netstat который уже 10 лет deprecated(используйте ss и lsof)
> sftp/scp. Столь же прост, но более устойчив к недобрым людям живущим на пути ваших пакетов.
Вы не очень внимательны в чтении комментариев. Все уже было указано.
> sftp/scp. Столь же прост, но более устойчив к недобрым людям живущим на пути ваших пакетов.
Вы не очень внимательны в чтении комментариев. Все уже было указано.
Да он школьник с апломбом просто, зачем вы его слушаете? Все прекрасно и с `netstat` и c `ftp` (пока вы не гоняете туда-сюда кредитные карточки клиентов, конечно.) sftp — это мертворожденный уродец, а `scp`, как и все поверх `ssh`, дает в некоторых случаях стопроцентный и более оверхед.
Пусть живет в своем мирке с «новыми» технологиями, не мешайте вы ему :)
Пусть живет в своем мирке с «новыми» технологиями, не мешайте вы ему :)
чем устарел ftp? во первых существуют миллионы устройств которые не имеют другого протокола для переноса файлов (ну, может ещё tftp). не говорю о милионах хостингов, и разного всякого софтвара котрый тоже с ничем другим не работает. для начала милионов 100 сайтов под вордпрессом ;)
Первое что я делаю приходя к новому клиенту это объясняю, что использование ftp — идиотизм(некриптованная передача логина-пароля, некриптованная передача файлов) и удаляю ftp-демон к лягушачьей бабушке, если клиент способен понимать слова.
Про миллиарды сайтов на вордпрессе да сколько угодно, но лучше уж используйте всякие его родные файл-менеджеры, чем запускайте уязвимый фтп-демон(а они все дырявые, посмотрите данные по всяким proftpd, vsftpd и ко, разве что pure-ftpd как-то держится).
ftp устарел так же, как устарел gopher, но гофер выкинули на помойку истории, а труп фтп отдельные некрофилы все еще насилуют.
Про миллиарды сайтов на вордпрессе да сколько угодно, но лучше уж используйте всякие его родные файл-менеджеры, чем запускайте уязвимый фтп-демон(а они все дырявые, посмотрите данные по всяким proftpd, vsftpd и ко, разве что pure-ftpd как-то держится).
ftp устарел так же, как устарел gopher, но гофер выкинули на помойку истории, а труп фтп отдельные некрофилы все еще насилуют.
они все дырявые, посмотрите данные по всяким proftpd, vsftpd
Вы про этот vsftpd или какой-то другой?
ftp вас ещё прекрасно переживёт. о конкретных демонах разговора нет. ну, а те кто приходят к нам рассказывать какие протоколы для нас опасны и что надо одинсталировать — учатся считать ступеньки от шестого этажа, сразу за свидетелями еговы и страховыми агентами.
Они раньше перевели отличную How Linux Works / Внутреннее устройство Linux, но она больше про работу системы, а не скрипты на баше.
А на какой язык они ее перевели?
«Представлены также внедренные системы, например Android и OpenWRT»
Кем и куда внедренные системы? Или это просто переводчик не знал, что системы «встраиваемые»?
«Представлены также внедренные системы, например Android и OpenWRT»
Кем и куда внедренные системы? Или это просто переводчик не знал, что системы «встраиваемые»?
Есть пара мест, где пришлось переводить написанное обратно и оформление хуже оригинала, но читается легко и очень полезный материал даётся в сжатом виде.
Про книгу Немет такого, к сожалению, не скажешь и она уже сильно устарела — ни слова про systemd, firewalld и настройку SELinux, зато куча сендмейла и вымирающих юниксов.
Про книгу Немет такого, к сожалению, не скажешь и она уже сильно устарела — ни слова про systemd, firewalld и настройку SELinux, зато куча сендмейла и вымирающих юниксов.
Всякие netstat, fdisk с MBR (GPT не всем нужен), ftp, ifconfig — это «классика» проверенная временем.
На то она и книга, тем более по IT, чтобы освещать некие базовые и самые широко распространенные вещи.
Тот же ifconfig был 10 лет назад, сейчас есть и еще 10 лет будет. Если надо IP адрес посмотреть зачем что-то сложнее ifconfig?
Надо ведь понимать, что каждый инструмент имеет свои ограничения. Эти инструменты старые, может не слишком функциональные. Но если свои задачи выполняет, то незачем их заменять?
90% книги актуальна сейчас и будет актуальна еще долго. Она ведь для новичков, по большому счету.
Кому их мало функционала, пользуйтесь ss, lsof, jq и прочим. Кто мешает?
Можно подумать, те, кто использовал или используют netstat, никогда не будут работать с lsof. Мне, например в 90% хватает netstat-a.
> передача файлов по ftp(руки отрывать за такие идеи).
Чем ftp не угодил? Чем его заменить таким же простым?
На то она и книга, тем более по IT, чтобы освещать некие базовые и самые широко распространенные вещи.
Тот же ifconfig был 10 лет назад, сейчас есть и еще 10 лет будет. Если надо IP адрес посмотреть зачем что-то сложнее ifconfig?
Надо ведь понимать, что каждый инструмент имеет свои ограничения. Эти инструменты старые, может не слишком функциональные. Но если свои задачи выполняет, то незачем их заменять?
90% книги актуальна сейчас и будет актуальна еще долго. Она ведь для новичков, по большому счету.
Кому их мало функционала, пользуйтесь ss, lsof, jq и прочим. Кто мешает?
Можно подумать, те, кто использовал или используют netstat, никогда не будут работать с lsof. Мне, например в 90% хватает netstat-a.
> передача файлов по ftp(руки отрывать за такие идеи).
Чем ftp не угодил? Чем его заменить таким же простым?
> Тот же ifconfig был 10 лет назад, сейчас есть и еще 10 лет будет. Если надо IP адрес посмотреть зачем что-то сложнее ifconfig?
ifconfig устарел и не способен выполнять свои функции уже давно. Он сохраняется только для обратной совместимости. Посмотреть адрес проще использовав ip a s [name_dev]. Мне уже кто-то жаловался, что зайдя на свежепоставленный CentOS не обнаружил там ifconfig, только ip. Так и вы заучивая устаревшие команды в один грустный день не поймете что же делать.
> те, кто использовал или используют netstat, никогда не будут работать с lsof.
Опять же завтра зайдя на свежепоставленный сервер вы можете обнаружить, что netstat выкинули, ибо он давно deprecated.
> Чем ftp не угодил? Чем его заменить таким же простым?
sftp/scp. Столь же прост, но более устойчив к недобрым людям живущим на пути ваших пакетов.
ifconfig устарел и не способен выполнять свои функции уже давно. Он сохраняется только для обратной совместимости. Посмотреть адрес проще использовав ip a s [name_dev]. Мне уже кто-то жаловался, что зайдя на свежепоставленный CentOS не обнаружил там ifconfig, только ip. Так и вы заучивая устаревшие команды в один грустный день не поймете что же делать.
> те, кто использовал или используют netstat, никогда не будут работать с lsof.
Опять же завтра зайдя на свежепоставленный сервер вы можете обнаружить, что netstat выкинули, ибо он давно deprecated.
> Чем ftp не угодил? Чем его заменить таким же простым?
sftp/scp. Столь же прост, но более устойчив к недобрым людям живущим на пути ваших пакетов.
> ifconfig устарел и не способен выполнять свои функции уже давно.
Если ifconfig не делает того, что написано в его документациии, значит ошибка в программе.
Иначе он выполняет свои функции. Другой вопрос, что набор функций невелик.
> Так и вы заучивая устаревшие команды в один грустный день не поймете что же делать.
Такие изменения происходят не вдруг. Грамотный подход — это ведь не заучивание команд, а понимание принципов.
Это ведь то же самое, если бы в этой книге написали бы про самую продвинутую утилиту на сегодняшний день, а через 20 лет она так же устареет, а ее выкинут.
В книге нужен пример, для него берется то, что давно используется и широко известно. Кто после прочтения главы поймет, что ifconfig не справляется. Быстро найдет альтернативу.
> sftp/scp. Столь же прост, но более устойчив к недобрым людям живущим на пути ваших пакетов.
Тоже хороший вариант.
Но многие данные не требуют защиты т.к. или тривиальны или легко доступны в других местах.
Но когда надо организовать архив файлов не представляющих никакой ценности для окружающих или в какой-нибудь очень локальной сети, то ftp вполне справляется.
Поэтому так категорично я бы не стал его выкидывать.
Нужно подбирать инструмент под задачу.
Если утилита удовлетворяет всем требованиям — берем. Если не удовлетворяте, то это негодная утилита для конкретной задачи. Вопрос может только так ставится. Ну и немного вкусовщины может быть, например выбрать ту утилиту, где конфиги в простом текстовом формате, а не в XML.
Если ifconfig не делает того, что написано в его документациии, значит ошибка в программе.
Иначе он выполняет свои функции. Другой вопрос, что набор функций невелик.
> Так и вы заучивая устаревшие команды в один грустный день не поймете что же делать.
Такие изменения происходят не вдруг. Грамотный подход — это ведь не заучивание команд, а понимание принципов.
Это ведь то же самое, если бы в этой книге написали бы про самую продвинутую утилиту на сегодняшний день, а через 20 лет она так же устареет, а ее выкинут.
В книге нужен пример, для него берется то, что давно используется и широко известно. Кто после прочтения главы поймет, что ifconfig не справляется. Быстро найдет альтернативу.
> sftp/scp. Столь же прост, но более устойчив к недобрым людям живущим на пути ваших пакетов.
Тоже хороший вариант.
Но многие данные не требуют защиты т.к. или тривиальны или легко доступны в других местах.
Но когда надо организовать архив файлов не представляющих никакой ценности для окружающих или в какой-нибудь очень локальной сети, то ftp вполне справляется.
Поэтому так категорично я бы не стал его выкидывать.
Нужно подбирать инструмент под задачу.
Если утилита удовлетворяет всем требованиям — берем. Если не удовлетворяте, то это негодная утилита для конкретной задачи. Вопрос может только так ставится. Ну и немного вкусовщины может быть, например выбрать ту утилиту, где конфиги в простом текстовом формате, а не в XML.
Навскидку:
* ifconfig не отображает всех адресов интерфейса (в linux).
* Навесить больше одного нельзя.
* Снять адрес с интерфейса нельзя.
Во FreeBSD это все закостылили через ifconfig dev alias
Живой пример:
На мой взгляд (после беглого чтения LARTC), iproute2 куда удобнее богатого разнообразия устаревших утилит.
* ifconfig не отображает всех адресов интерфейса (в linux).
* Навесить больше одного нельзя.
* Снять адрес с интерфейса нельзя.
Во FreeBSD это все закостылили через ifconfig dev alias
Живой пример:
[root@server1101 ~]# ifconfig eth1.5
eth1.5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.21.0.36 netmask 255.255.255.0 broadcast 10.21.0.255
ether XX:XX:XX:XX:XX:XX txqueuelen 0 (Ethernet)
RX packets 18741038683 bytes 2738418377826 (2.4 TiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11535933635 bytes 24058416457149 (21.8 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@server1101 ~]# ip a s dev eth1.5
8: eth1.5@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 10.21.0.36/24 brd 10.21.0.255 scope global eth1.5
valid_lft forever preferred_lft forever
inet 10.21.12.212/16 brd 10.21.255.255 scope global eth1.5
valid_lft forever preferred_lft forever
[root@server1101 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1.5
DEVICE="eth1.5"
ONBOOT=yes
NETBOOT=yes
IPV6INIT=no
PEERDNS=no
BOOTPROTO=static
IPADDR0=10.21.0.36
PREFIX0=24
IPADDR1=10.21.12.212
PREFIX1=16
VLAN=yes
NM_CONTROLLED=no
На мой взгляд (после беглого чтения LARTC), iproute2 куда удобнее богатого разнообразия устаревших утилит.
То, что молотком довольно непросто завернуть шуруп, не делает его плохим инструментом. Когда мне быстро нужно глянуть, что мне по DHCP выдал роутер, я как вызывал 15 лет назад `ifconfig`, так и буду делать то же самое еще 15 лет спустя.
* ifconfig не отображает всех адресов интерфейса (в linux).
* Навесить больше одного нельзя.
Стандартный гуй в RHEL также себя ведёт, а дополнительные адреса там принято добавлять через сабинтерфейсы:
eth0 Link encap:Ethernet HWaddr 00:0C:29:AC:1E:26
inet addr:10.2.9.5 Bcast:10.2.9.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feac:1e26/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10924221 errors:0 dropped:0 overruns:0 frame:0
TX packets:6251638 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6974724562 (6.4 GiB) TX bytes:6426851488 (5.9 GiB)
eth0:1 Link encap:Ethernet HWaddr 00:0C:29:AC:1E:26
inet addr:10.2.9.6 Bcast:10.2.9.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:2 Link encap:Ethernet HWaddr 00:0C:29:AC:1E:26
inet addr:10.2.9.7 Bcast:10.2.9.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Нисколь не умаляя возможности стандартного гуя в RHEL и предпочтения приверженцев net-tools в целом, все же считаю, что в linux net-tools уже не нужны (ну или нужны в порядке совместимости).
https://en.wikipedia.org/wiki/Ifconfig#Related_tools
Там выше был комментарий
Тут как получается: route, ifconfig, netstat, vconfig, brctl, arp да много ли чего еще, часть из которых вовсе не входит в net-tools.
Iproute2: просто команда ip (кроме шейпинга).
В целом, похоже развивается холивар, не думаю, что есть смысл его поддерживать. По своему лишь опыту скажу, что при настройке своего домашнего сервера для настройки сети так, чтобы все работало так, как требовалось, мне надоело компилить каждый раз под гентой очередную новую утилитку. Некоторые вещи вообще не могли решить net-tools (как например доступность сервера с двух аплинков).
Да, добавлю: все вышесказанное актуально только для Linux. В BSD системах эти утилиты активно развиваются. Но опять же: ifconfig, setfiber (причем количество таблиц устанавливается в ядре!) и пр.пр.
https://en.wikipedia.org/wiki/Ifconfig#Related_tools
Some Linux distributions have deprecated the use of ifconfig and route in favor of the software suite iproute2,[3] which has been available since 1999 for Linux 2.2.[4] iproute2 includes support for all common functions of ifconfig(8), route(8), arp(8) and netstat(1). It also includes multicast configuration support, tunnel and virtual link management, traffic control, and low-level IPsec configuration, among other features.
Там выше был комментарий
Люди, которые действительно работают с юниксами, а не дрочат настройки по ночам на всех доступных серверах, никогда не скажут такую глупость, как `ifconfig` устарел.
Тут как получается: route, ifconfig, netstat, vconfig, brctl, arp да много ли чего еще, часть из которых вовсе не входит в net-tools.
Iproute2: просто команда ip (кроме шейпинга).
В целом, похоже развивается холивар, не думаю, что есть смысл его поддерживать. По своему лишь опыту скажу, что при настройке своего домашнего сервера для настройки сети так, чтобы все работало так, как требовалось, мне надоело компилить каждый раз под гентой очередную новую утилитку. Некоторые вещи вообще не могли решить net-tools (как например доступность сервера с двух аплинков).
Да, добавлю: все вышесказанное актуально только для Linux. В BSD системах эти утилиты активно развиваются. Но опять же: ifconfig, setfiber (причем количество таблиц устанавливается в ядре!) и пр.пр.
Комментарий был мой, поэтому скажу: я не знаю уж, зачем вам на сервере генту, но даже там, я уверен, `ifconfig` есть из коробки (ну из того минимального набора, без которого сеть вообще не поднимется). Для того, чтобы настраивать сервера у меня есть вон такие крутые админы, как этот 36-летний спец, которые знают в лицо все стопиццот современных утилит.
Мне же вполне хватает `ifconfig`, и из-за таких как я его никогда не перестанут поддерживать, хоть тушкой, хоть чучелом, хоть алиасом на расово-верную современную команду с пятнадцатью параметрами.
Мне же вполне хватает `ifconfig`, и из-за таких как я его никогда не перестанут поддерживать, хоть тушкой, хоть чучелом, хоть алиасом на расово-верную современную команду с пятнадцатью параметрами.
Ну здесь вопрос нужды. В моем случае дело не в генте (и что в ней надо что-то компилить), а в том, что базовыми инструментами в текущий момент даже не все тривиальные ситуации решить могут. Как я уже выше писал: для бриджа — извольте bridge-utils, для тегированного трафика — vconfig. route не умеет работать с несколькими таблицами. net-tools сейчас вообще не развивается в linux, в отличие от BSD.
В моем случае отказ от них был вызван в связи с необходимостью, а не с вопросом «больше нравится».
В моем случае отказ от них был вызван в связи с необходимостью, а не с вопросом «больше нравится».
А книжка, кстати, толковая. Понятно, что любая книга не угонится за прогрессом, но базовые понятия даются хорошо: для толкового новичка даст возможность развиваться.
Простите, а чем плохи ifconfig, netstat и fdisk? Тот же ifconfig часто использую для проверки состояния интерфейсов, причем больше интересует количество входящих/исходящих пакетов. Fdisk дает неплохие данные о разделах, в том числе созданных при помощи parted. Netstat же первое что приходит в голову когда надо посмотреть активные сетевые сессии. Цель книги, я так понимаю, научить пользоваться командной строкой, а уже инструменты человек подберет себе сам.
P.S. В комментариях уже ответили.
P.S. В комментариях уже ответили.
ifconfig не может добавить несколько адресов на интерфейс(про алиасы не нужно, именно на интефейс, а не создавая левые интефейсы), netstat объявлен deprecated и может быть в любой момент выброшен без дальнейших предупреждений и учить использовать его — глупость, fdisk в книге позиционируется для создания разделов, а он не может их создавать на GPT-дисках о чем он прямо скажет бедному ребенку взявшему эту книгу в руки.
> Netstat же первое что приходит в голову когда надо посмотреть активные сетевые сессии.
Кому приходит? Вам? А мне приходит в голову lsof и именно мой вариант правильный, так считает вся документация.
> Netstat же первое что приходит в голову когда надо посмотреть активные сетевые сессии.
Кому приходит? Вам? А мне приходит в голову lsof и именно мой вариант правильный, так считает вся документация.
Да, но ifconfig и net-stat входят в пакет утилит net-tools, поддержка которого будет продолжаться еще очень долго.
Так как netstat объявлен deprecated больше 10 лет назад его в любой момент может не оказаться в net-tools, вот просто может завтра выйти обновление в котором будет сказано «А мы его дропнули, всех же предупреждали». Про системы без ifconfig'а я уже писал, мне недавно один такой начитавшийся подобных книжонок ребенок жаловался, что зашел на CentOS, а ifconfig'а и нет. Я уж не стал разбираться что это был за чудо-CentOS, а просто сказал «Используй ip, как нормальные люди», но во вреде подобных книжек убедился в очередной раз.
а что если ss религия запрещает использовать?
Пролистывал эту книгу. Ведение в командную строку (первая часть) и основы написания скриптов (последняя часть) описаны неплохо. Местами, конечно, устарела, но в целом мне понравилась.
В оригинале доступна бесплатно: http://linuxcommand.org/tlcl.php
А это книга подойдет, как учебное пособие по Линукс-серверу, для начинающих?
Как вводный материал может и не плохо. А вот если уже годами пользуюсь но хочется поглубже да по основателеьней?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Книга «Командная строка Linux. Полное руководство»