Используем grep для поиска в файлах и потоках
Любой Linux администратор сталкивался с командой grep, которая используется для поиска строк по шаблону в стандартных потоках и текстовых файлах.
Изначально grep был написан одним из основателей UNIX Кеном Томпсоном, когда его начальник Дуглас Макилрой попросил его написать инструмент «для поиска чего-нибудь в файлах». Название утилиты происходит от global regular expression print (глобальный вывод регулярных выражений)
Самый частый сценарий использования grep, когда нам нужно отфильтровать поток ввода-вывода, например:
Также он может работать и с файлами, хотя многие используют совершенно излишнее:
В то время, когда можно просто использовать:
Но бывает недостаточно просто найти искомое значение, часто бывает нужно получить также его контекст, это, например, важно при разборе логов, для этого используйте специальные ключи:
-A (after) – выводит указанное число сток после вхождения
- B (before) – выводит указанное число строк до вхождения
-С (context) – выводит указанное число строк до и после вхождения.
Например, если нам нужно вывести следующие пять строк после найденного вхождения используйте:
Если вам наоборот нужно сократить вывод и найти только вхождения, то используйте ключ -o, его удобно сочетать с ключом -n, который выводит номера строк.
Например:
Выдаст:
Также grep умеет искать по нескольким файлам сразу, в этом случае перед выводом искомой строки будет указано имя файла, если вам нужно вывести только имена файлов, в которых найдены вхождения используйте ключ -l:
И наоборот, ключ
Для того, чтобы игнорировать регистр символов предназначен ключ -i, а ключ -v инвертирует шаблон запроса, так команда:
Выведет те строки, где нет вхождения указанного шаблона, часто применяется для того, чтобы вывести содержимое конфигурационного файла без комментариев.
И, наконец, grep может использовать регулярные выражения, для этого укажите ключ -E, например, поиск российских телефонных номеров в файле:
Несмотря на то, что grep понимает многие подстановочные символы при использовании поиска по регулярным выражениям рекомендуется всегда использовать ключ -E, что позволит избежать неожиданных результатов.
В этом месте читатели могут вспомнить утилиту egrep, но в настоящий момент она, как и fgrep, объявлена устаревшей и лучше отвыкать от ее использования.
Несмотря на то, что указанные утилиты сохраняются практически во всех дистрибутивах для обеспечения обратной совместимости лучше сразу переходить на актуальные grep -E и grep -F.
Кстати, grep -F – это полная противоположность grep -E, данный ключ предписывает игнорировать метасимволы и подстановочные данные и будет искать строку как есть:
Например:
Будет искать строго то, что написано, это может понадобится при поиске специфической информации, скажем, математических выражений, как в этом примере.
Любой Linux администратор сталкивался с командой grep, которая используется для поиска строк по шаблону в стандартных потоках и текстовых файлах.
Изначально grep был написан одним из основателей UNIX Кеном Томпсоном, когда его начальник Дуглас Макилрой попросил его написать инструмент «для поиска чего-нибудь в файлах». Название утилиты происходит от global regular expression print (глобальный вывод регулярных выражений)
Самый частый сценарий использования grep, когда нам нужно отфильтровать поток ввода-вывода, например:
dpkg -l | grep gimpТакже он может работать и с файлами, хотя многие используют совершенно излишнее:
cat file.txt | grep mystringВ то время, когда можно просто использовать:
grep mystring file.txtНо бывает недостаточно просто найти искомое значение, часто бывает нужно получить также его контекст, это, например, важно при разборе логов, для этого используйте специальные ключи:
-A (after) – выводит указанное число сток после вхождения
- B (before) – выводит указанное число строк до вхождения
-С (context) – выводит указанное число строк до и после вхождения.
Например, если нам нужно вывести следующие пять строк после найденного вхождения используйте:
grep -A5 mystring file.txtЕсли вам наоборот нужно сократить вывод и найти только вхождения, то используйте ключ -o, его удобно сочетать с ключом -n, который выводит номера строк.
Например:
grep -no mystring file.txtВыдаст:
5:mystring9:mystring25:mystringТакже grep умеет искать по нескольким файлам сразу, в этом случае перед выводом искомой строки будет указано имя файла, если вам нужно вывести только имена файлов, в которых найдены вхождения используйте ключ -l:
grep -l mystring file.txt file1.txt file2.txt file3.txtИ наоборот, ключ
-L позволяет вывести имена файлов в которых вхождение не найдено.Для того, чтобы игнорировать регистр символов предназначен ключ -i, а ключ -v инвертирует шаблон запроса, так команда:
grep -v mystring file.txtВыведет те строки, где нет вхождения указанного шаблона, часто применяется для того, чтобы вывести содержимое конфигурационного файла без комментариев.
И, наконец, grep может использовать регулярные выражения, для этого укажите ключ -E, например, поиск российских телефонных номеров в файле:
grep -E ^((8|\+7)[\- ]?)?(\(?\d{3}\)?[\- ]?)?[\d\- ]{7,10}$ file.txtНесмотря на то, что grep понимает многие подстановочные символы при использовании поиска по регулярным выражениям рекомендуется всегда использовать ключ -E, что позволит избежать неожиданных результатов.
В этом месте читатели могут вспомнить утилиту egrep, но в настоящий момент она, как и fgrep, объявлена устаревшей и лучше отвыкать от ее использования.
Несмотря на то, что указанные утилиты сохраняются практически во всех дистрибутивах для обеспечения обратной совместимости лучше сразу переходить на актуальные grep -E и grep -F.
Кстати, grep -F – это полная противоположность grep -E, данный ключ предписывает игнорировать метасимволы и подстановочные данные и будет искать строку как есть:
Например:
grep -F 2*(x+y)^2 file.txtБудет искать строго то, что написано, это может понадобится при поиске специфической информации, скажем, математических выражений, как в этом примере.
👍47🔥4
В соседнем канале выложили такую вот бумагу. Чем она интересна?
1. Регулятор запрашивает у получателей данной рассылки сведения об используемых ими протоколах.
2. Указывает на те сервисы и протоколы, которые подлежат блокировке.
В их числе "хваленый" Shadowsocks, причем в силу его практической непригодности для корпоративных коммуникаций его блокировка видится делом ближайшего будущего.
А вот классические протоколы: PPTP, L2TP и OpenVPN как ходили, так и будут ходить, так как широко используются в корпоративной среде.
Тоже самое, скорее всего, справедливо будет и для WireGuard. Несмотря на то, что протокол относительно новый его уже достаточно широко используют в производственных целях.
А рубить широко и с плеча сегодня никто не будет, так как VPN нужен очень многим, в том числе и трансграничный.
В этом ключе все летние блокировки видятся именно как проверка: кого и как сильно заденет блокировка протокола, чтобы оценить ситуацию и скорректировать цели.
1. Регулятор запрашивает у получателей данной рассылки сведения об используемых ими протоколах.
2. Указывает на те сервисы и протоколы, которые подлежат блокировке.
В их числе "хваленый" Shadowsocks, причем в силу его практической непригодности для корпоративных коммуникаций его блокировка видится делом ближайшего будущего.
А вот классические протоколы: PPTP, L2TP и OpenVPN как ходили, так и будут ходить, так как широко используются в корпоративной среде.
Тоже самое, скорее всего, справедливо будет и для WireGuard. Несмотря на то, что протокол относительно новый его уже достаточно широко используют в производственных целях.
А рубить широко и с плеча сегодня никто не будет, так как VPN нужен очень многим, в том числе и трансграничный.
В этом ключе все летние блокировки видятся именно как проверка: кого и как сильно заденет блокировка протокола, чтобы оценить ситуацию и скорректировать цели.
🤡28👍24🤔4👎1👌1
Полезная для начинающих утилита с неприличным именем
Работая в консоли Linux, начинающие делают ошибки, это нормально. Гораздо хуже, когда ее не удается быстро исправить или поиск информации затруднен.
В этом случае может пригодиться одна полезная утилита с неприличным именем - The Fuck, которое исправляет ошибки в введенных ранее консольных командах.
Утилита разработана на Python и для ее установки выполните:
Обратите внимание, что саму утилиту, в отличие от зависимостей, следует устанавливать с правами того пользователя, который будет ей пользоваться, а ключ
После чего в файл
Которая добавит для команды алиас
Затем перечитайте значения из файла или перезапустите сеанс:
Теперь можно попробовать утилиту в деле. Вводим команду с ошибкой, после чего вызываем
Утилита тут же предлагает нам исправление, достаточно нажать Enter, но теперь снова ошибка, мы запустили команду с недостаточным набором прав. Снова вызываем утилиту, и она нас снова поправляет.
Чтобы избежать постоянного вызова утилиты можно запустить ее в режиме повторения:
Теперь она будет последовательно обрабатывать все полученные ошибки до получения результата, либо пока вы не прервете ее действия.
Если вы хотите применять исправления автоматически, то вызовите утилиту с ключом:
Но полностью полагаться на искусственный интеллект неразумно и небезопасно, поэтому разработчики отключили автоматическое подтверждение в режиме повторения.
Больше об утилите можно узнать на официальной странице Git: https://github.com/nvbn/thefuck
Работая в консоли Linux, начинающие делают ошибки, это нормально. Гораздо хуже, когда ее не удается быстро исправить или поиск информации затруднен.
В этом случае может пригодиться одна полезная утилита с неприличным именем - The Fuck, которое исправляет ошибки в введенных ранее консольных командах.
Утилита разработана на Python и для ее установки выполните:
sudo apt install python3-dev python3-pip python3-setuptoolspip install thefuck -–userОбратите внимание, что саму утилиту, в отличие от зависимостей, следует устанавливать с правами того пользователя, который будет ей пользоваться, а ключ
-–user предписывает установить утилиту только для текущего пользователя.После чего в файл
.bashrc внести строку:eval $(thefuck --alias fuck)Которая добавит для команды алиас
fuck, если вам ближе родная речь, то можете написать:eval $(thefuck --alias blya)Затем перечитайте значения из файла или перезапустите сеанс:
source .bashrcТеперь можно попробовать утилиту в деле. Вводим команду с ошибкой, после чего вызываем
fuckУтилита тут же предлагает нам исправление, достаточно нажать Enter, но теперь снова ошибка, мы запустили команду с недостаточным набором прав. Снова вызываем утилиту, и она нас снова поправляет.
Чтобы избежать постоянного вызова утилиты можно запустить ее в режиме повторения:
fuck -r Теперь она будет последовательно обрабатывать все полученные ошибки до получения результата, либо пока вы не прервете ее действия.
Если вы хотите применять исправления автоматически, то вызовите утилиту с ключом:
fuck -yНо полностью полагаться на искусственный интеллект неразумно и небезопасно, поэтому разработчики отключили автоматическое подтверждение в режиме повторения.
Больше об утилите можно узнать на официальной странице Git: https://github.com/nvbn/thefuck
😁22👍14🔥2👀2
Употребляете ли вы "крепкие" выражения?
Anonymous Poll
28%
Да, постоянно
27%
Да, время от времени
23%
Да, во время крепких эмоций
10%
Редко
3%
Нет, но понимаю тех кто употребляет
4%
Нет и решительно осуждаю
0%
Употребляю сугубо не тревзым
5%
Ничего не понятно, но очень интересно
👍7😁7
KISS (Keep it simple stupid, «не усложняй, придурок»)
Работая с различными заказчиками, очень часто приходится вспоминать этот принцип. Потому как многие коллеги, особенно молодые, очень любят переусложнять системы.
Когда в сети на 5-7 узлов встречаешь ActiveDirectory, развернутую на единственном сервере, там же еще крутится 1С, СУБД и всякое прочее – берет оторопь.
Причем никакой виртуализацией там не пахнет, потому что виртуализация – это сложно.
А насколько просто будет поддерживать и сопровождать этого монстрика Франкенштейна – никто и не думает.
Если заглянуть в набор правил брандмауэра, то мы увидим там кучу правил с заковыристыми критериями, типа TCP-флагов и прочего, чего сам коллега и толком пояснить не может.
На вопрос: «зачем?»
Поясняют, что: «Защита от сетевых атак»
На следующий вопрос: «А вас кто-то атакует?» тоже остается без ответа.
По имеющимся сообщениям, акроним был придуман Кларенсом Джонсоном, ведущим инженером Lockheed Skunk Works, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами.
Такой же принцип будет не лишним и в IT, когда специалист среднего уровня и квалификации должен разобраться и починить ваше «творчество» подручными средствами.
Тем более в эпоху виртуализации делать проще становится еще легче. Никто не мешает разнести нам сервисы и сервера по отдельным виртуалкам или контейнерам, чтобы исключить их влияние на соседей.
А аппаратные ресурсы для этого способен предоставить любой бытовой ПК среднего уровня.
Работая с различными заказчиками, очень часто приходится вспоминать этот принцип. Потому как многие коллеги, особенно молодые, очень любят переусложнять системы.
Когда в сети на 5-7 узлов встречаешь ActiveDirectory, развернутую на единственном сервере, там же еще крутится 1С, СУБД и всякое прочее – берет оторопь.
Причем никакой виртуализацией там не пахнет, потому что виртуализация – это сложно.
А насколько просто будет поддерживать и сопровождать этого монстрика Франкенштейна – никто и не думает.
Если заглянуть в набор правил брандмауэра, то мы увидим там кучу правил с заковыристыми критериями, типа TCP-флагов и прочего, чего сам коллега и толком пояснить не может.
На вопрос: «зачем?»
Поясняют, что: «Защита от сетевых атак»
На следующий вопрос: «А вас кто-то атакует?» тоже остается без ответа.
По имеющимся сообщениям, акроним был придуман Кларенсом Джонсоном, ведущим инженером Lockheed Skunk Works, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами.
Такой же принцип будет не лишним и в IT, когда специалист среднего уровня и квалификации должен разобраться и починить ваше «творчество» подручными средствами.
Тем более в эпоху виртуализации делать проще становится еще легче. Никто не мешает разнести нам сервисы и сервера по отдельным виртуалкам или контейнерам, чтобы исключить их влияние на соседей.
А аппаратные ресурсы для этого способен предоставить любой бытовой ПК среднего уровня.
💯41👍19
Караван-сарай или величественный собор?
Наткнулся я тут случайно на такой проект, как CBSD, это это обёртка из sh-скриптов (преимущественно) вокруг подсистемы jail(8), гипервизоров bhyve, QEMU / NVMM и Xen для BSD операционных систем.
Какого-либо нового функционала в ОС на данном этапе не внесено — всё, что могут делать скрипты CBSD, можно сделать командой (командами, десятками, сотнями команд) в CLI через соответствующие утилиты.
Глядя на сайт, я сначала подумал, что это еще один заброшенный проект десятилетней давности, но нет, проект жив и даже куда-то там барахтается…
При том, что на дворе 2023 год и в мире Linux давно есть мощные и удобные продукты виртуализации, такие как Proxmox.
И здесь снова и снова вспоминаешь старое высказывание разработчиков FreеBSD про караван-сарайный принцип разработки Linux, где систему могут дорабатывать все, кто не лень, в противопоставление которому ставились принципы разработки FreeBSD, которую они сравнивали с величественным собором, который возводит небольшая группа архитекторов.
Время расставило все на свои места и Linux из караван-сарая превратился в современный технопарк, а величественный собор так и стоит недостроенным.
При этом за последние 10-15 лет FreeBSD серьезно утратила позиции превратившись в ОС для энтузиастов и маргиналов. Ну и то место, где код можно взять и ничего назад не отдавать.
И все эти заявления, мол BSD используется в macOS, PlayStation, Juniper, NetApp и т.д. выглядят нелепо и смешно, на уровне школьных разборок: «а у меня брат – каратист».
Действительно, кивать на более успешные проекты можно только в отсутствие собственных достижений. Тем более, что все вышеперечисленное – закрытые коммерческие ОС и никто не знает сколько там чего от FreeBSD и насколько это переписано.
А со своим там действительно все плохо, на попытку разработать собственную графическую оболочку с использованием только BSD технологий - Lumina без слез не глянешь.
С доставшейся по наследству ZFS тоже приключилась неприятность, так как из всех вариаций ZFS наиболее активно развивалась ZFS on Linux, то в 2018 году было принято решение, что новая версия OpenZFS 2.0 будет базироваться на кодовой базе для Linux и уже из нее портироваться на другие системы.
Ну и наконец старая история с использованием кода BSD в стеке TCP/IP Windows, которую можно охарактеризовать словами: слышал звон, да не знаю где он.
При выпуске на рынок Windows 3.11 Microsoft потребовалось добавить туда поддержку TCP/IP, а так как собственный стек еще был в разработке, то было лицензировано решение от компании Spider Systems, которое было написано с применением кода FreeBSD. С ним же в Windows попали основанные на коде BSD утилиты, предназначенные для нового стека ftp, rcp и rsh и т.п.
Но у стека Spider был один существенный недостаток, он был завязан на собственную среду STREAMS, которую тоже пришлось портировать на Windows и нести связанные с ней накладные расходы.
Собственный стек TCP/IP Microsoft, созданный с нуля, вышел в конце 1994 года и поставлялся с Windows NT, а также позже вошел в состав Windows 95.
Но, несмотря на новый стек, часть утилит переписывать не стали и оставили прежними. Действительно, зачем переписывать клиент FTP если он хорошо работает и законным образом лицензирован? Но именно последний момент, а именно отсылка к лицензии BSD и дала повод различным досужим теориям о BSD стеке TCP/IP в Windows.
А мы еще раз глянем на картинку ниже: справа величественный собор, слева – караван-сарай. Не перепутай!
Наткнулся я тут случайно на такой проект, как CBSD, это это обёртка из sh-скриптов (преимущественно) вокруг подсистемы jail(8), гипервизоров bhyve, QEMU / NVMM и Xen для BSD операционных систем.
Какого-либо нового функционала в ОС на данном этапе не внесено — всё, что могут делать скрипты CBSD, можно сделать командой (командами, десятками, сотнями команд) в CLI через соответствующие утилиты.
Глядя на сайт, я сначала подумал, что это еще один заброшенный проект десятилетней давности, но нет, проект жив и даже куда-то там барахтается…
При том, что на дворе 2023 год и в мире Linux давно есть мощные и удобные продукты виртуализации, такие как Proxmox.
И здесь снова и снова вспоминаешь старое высказывание разработчиков FreеBSD про караван-сарайный принцип разработки Linux, где систему могут дорабатывать все, кто не лень, в противопоставление которому ставились принципы разработки FreeBSD, которую они сравнивали с величественным собором, который возводит небольшая группа архитекторов.
Время расставило все на свои места и Linux из караван-сарая превратился в современный технопарк, а величественный собор так и стоит недостроенным.
При этом за последние 10-15 лет FreeBSD серьезно утратила позиции превратившись в ОС для энтузиастов и маргиналов. Ну и то место, где код можно взять и ничего назад не отдавать.
И все эти заявления, мол BSD используется в macOS, PlayStation, Juniper, NetApp и т.д. выглядят нелепо и смешно, на уровне школьных разборок: «а у меня брат – каратист».
Действительно, кивать на более успешные проекты можно только в отсутствие собственных достижений. Тем более, что все вышеперечисленное – закрытые коммерческие ОС и никто не знает сколько там чего от FreeBSD и насколько это переписано.
А со своим там действительно все плохо, на попытку разработать собственную графическую оболочку с использованием только BSD технологий - Lumina без слез не глянешь.
С доставшейся по наследству ZFS тоже приключилась неприятность, так как из всех вариаций ZFS наиболее активно развивалась ZFS on Linux, то в 2018 году было принято решение, что новая версия OpenZFS 2.0 будет базироваться на кодовой базе для Linux и уже из нее портироваться на другие системы.
Ну и наконец старая история с использованием кода BSD в стеке TCP/IP Windows, которую можно охарактеризовать словами: слышал звон, да не знаю где он.
При выпуске на рынок Windows 3.11 Microsoft потребовалось добавить туда поддержку TCP/IP, а так как собственный стек еще был в разработке, то было лицензировано решение от компании Spider Systems, которое было написано с применением кода FreeBSD. С ним же в Windows попали основанные на коде BSD утилиты, предназначенные для нового стека ftp, rcp и rsh и т.п.
Но у стека Spider был один существенный недостаток, он был завязан на собственную среду STREAMS, которую тоже пришлось портировать на Windows и нести связанные с ней накладные расходы.
Собственный стек TCP/IP Microsoft, созданный с нуля, вышел в конце 1994 года и поставлялся с Windows NT, а также позже вошел в состав Windows 95.
Но, несмотря на новый стек, часть утилит переписывать не стали и оставили прежними. Действительно, зачем переписывать клиент FTP если он хорошо работает и законным образом лицензирован? Но именно последний момент, а именно отсылка к лицензии BSD и дала повод различным досужим теориям о BSD стеке TCP/IP в Windows.
А мы еще раз глянем на картинку ниже: справа величественный собор, слева – караван-сарай. Не перепутай!
👍30👎6🤷♂1❤1
Компания «Технологии Доверия» ищет специалистов в команду 1С!
В топовой аудиторско-консалтинговой фирме тебя ждет работа над развитием крупного международного проекта с 3000 пользователей и мощная прокачка экспертизы.
В ТеДо открыты следующие вакансии:
— Функциональный архитектор 1С (Учет затрат, себестоимость)
— Разработчик 1С (middle\senior)
Работа в ТеДо — это:
— оформление в штат по ТК РФ в аккредитованную ИТ-компанию
— гибкий формат работы: можно работать удаленно в РФ или в одном из 10 офисов в разных городах
— расширенный ДМС со стоматологией с первого месяца работы
— бесплатное внутреннее и внешнее обучение
— корпоративная техника и мобильная связь
Не упусти возможность построить свою траекторию успеха вместе с компанией «Технологии Доверия»! Откликайся на вакансии по ссылкам выше ⬆️
Реклама. ООО "ТЕХНОЛОГИИ ДОВЕРИЯ - КОНСУЛЬТИРОВАНИЕ". ИНН 7710764839.
В топовой аудиторско-консалтинговой фирме тебя ждет работа над развитием крупного международного проекта с 3000 пользователей и мощная прокачка экспертизы.
В ТеДо открыты следующие вакансии:
— Функциональный архитектор 1С (Учет затрат, себестоимость)
— Разработчик 1С (middle\senior)
Работа в ТеДо — это:
— оформление в штат по ТК РФ в аккредитованную ИТ-компанию
— гибкий формат работы: можно работать удаленно в РФ или в одном из 10 офисов в разных городах
— расширенный ДМС со стоматологией с первого месяца работы
— бесплатное внутреннее и внешнее обучение
— корпоративная техника и мобильная связь
Не упусти возможность построить свою траекторию успеха вместе с компанией «Технологии Доверия»! Откликайся на вакансии по ссылкам выше ⬆️
Реклама. ООО "ТЕХНОЛОГИИ ДОВЕРИЯ - КОНСУЛЬТИРОВАНИЕ". ИНН 7710764839.
👍2
Временные метки файлов в Linux
Этот, вроде-бы простой на первый взгляд вопрос часто вызывает достаточно много сложностей, особенно у начинающих.
Согласно стандарту POSIX у файлов в Linux имеются три временных метки:
▫️ atime – время последнего доступа к файлу
▫️ mtime – время последней модификации содержимого файла
▫️ ctime – время последнего изменения содержимого файла или его метаданных
С первой меткой вроде бы все просто, atime обновляется при любом доступе к файлу, например, при открытии. Но если файловая система смонтирована с опцией noatime данная метка обновляться не будет.
Метка mtime меняется при изменении содержимого файла, но ее не меняют изменения метаданных, такие как изменение владельца или прав доступа или переименование.
И, наконец, ctime, которая фиксирует любое изменение файла, будь то изменение содержимого или метаданных. Хотя во многих материалах метка ctime ошибочно описывается как время последнего изменения метаданных.
Особенностью метки ctime является то, что данная метка управляется системой, в то время как atime и mtime может произвольно изменять владелец файла. Таким образом данная метка однозначно покажет нам время последнего изменения файла, в то время как mtime может содержать неверную информацию.
При этом в нормальных условиях изменение mtime всегда влечет изменение ctime, а вот изменение ctime может происходить отдельно от других временных меток.
Так переименование файла изменит atime и ctime, но не затронет mtime, а изменение прав или владельца файла отразится только на ctime.
Позвольте, скажет иной читатель, а как быть с временем создания файла? А никак, такой временной метки POSIX не предусматривает. Однако позже была добавлена еще одна временная метка – crtime – которая как раз отражает время создания файла, но она имеет некоторые особенности.
Не являясь POSIX-совместимой, данная метка была реализована на уровне файловой системы и, следовательно, хранится только в ее пределах, между системами данный атрибут не переносится.
Таким образом данная метка отражает время создания файла в текущей файловой системе и при переносе файла между файловыми системами данная метка у него изменится, в то время как остальные временные метки будут сохранены.
Это может приводить к ситуации, показанной на рисунке ниже, когда время создания файла больше, чем время его модификации.
Каким образом можно посмотреть временные метки? Используйте команду stat, например:
Строки Доступ, Модифицирован и Изменен будут соответствовать atime, mtime и ctime. Однако если мы посмотрим на свойства файла в графическом окружении, то сможем увидеть, что Изменен в этом случае соответствует mtime, что в целом верно логически, но способно внести путаницу.
Поэтому, если вы хотите получить точное значение параметра, то используйте форматирование вывода команды stat:
Как видим, вроде бы простая тема оказалась не такой уж и простой. Но, если не пытаться переносить на Linux опыт других систем, а внимательно изучить теорию, то все станет на свои места и вы будете прекрасно понимать, что значит та или иная временная метка.
Этот, вроде-бы простой на первый взгляд вопрос часто вызывает достаточно много сложностей, особенно у начинающих.
Согласно стандарту POSIX у файлов в Linux имеются три временных метки:
▫️ atime – время последнего доступа к файлу
▫️ mtime – время последней модификации содержимого файла
▫️ ctime – время последнего изменения содержимого файла или его метаданных
С первой меткой вроде бы все просто, atime обновляется при любом доступе к файлу, например, при открытии. Но если файловая система смонтирована с опцией noatime данная метка обновляться не будет.
Метка mtime меняется при изменении содержимого файла, но ее не меняют изменения метаданных, такие как изменение владельца или прав доступа или переименование.
И, наконец, ctime, которая фиксирует любое изменение файла, будь то изменение содержимого или метаданных. Хотя во многих материалах метка ctime ошибочно описывается как время последнего изменения метаданных.
Особенностью метки ctime является то, что данная метка управляется системой, в то время как atime и mtime может произвольно изменять владелец файла. Таким образом данная метка однозначно покажет нам время последнего изменения файла, в то время как mtime может содержать неверную информацию.
При этом в нормальных условиях изменение mtime всегда влечет изменение ctime, а вот изменение ctime может происходить отдельно от других временных меток.
Так переименование файла изменит atime и ctime, но не затронет mtime, а изменение прав или владельца файла отразится только на ctime.
Позвольте, скажет иной читатель, а как быть с временем создания файла? А никак, такой временной метки POSIX не предусматривает. Однако позже была добавлена еще одна временная метка – crtime – которая как раз отражает время создания файла, но она имеет некоторые особенности.
Не являясь POSIX-совместимой, данная метка была реализована на уровне файловой системы и, следовательно, хранится только в ее пределах, между системами данный атрибут не переносится.
Таким образом данная метка отражает время создания файла в текущей файловой системе и при переносе файла между файловыми системами данная метка у него изменится, в то время как остальные временные метки будут сохранены.
Это может приводить к ситуации, показанной на рисунке ниже, когда время создания файла больше, чем время его модификации.
Каким образом можно посмотреть временные метки? Используйте команду stat, например:
stat file.txtСтроки Доступ, Модифицирован и Изменен будут соответствовать atime, mtime и ctime. Однако если мы посмотрим на свойства файла в графическом окружении, то сможем увидеть, что Изменен в этом случае соответствует mtime, что в целом верно логически, но способно внести путаницу.
Поэтому, если вы хотите получить точное значение параметра, то используйте форматирование вывода команды stat:
stat -c ‘%x’ file.txt - atimestat -c ‘%y’ file.txt - mtimestat -c ‘%z’ file.txt - ctimeКак видим, вроде бы простая тема оказалась не такой уж и простой. Но, если не пытаться переносить на Linux опыт других систем, а внимательно изучить теорию, то все станет на свои места и вы будете прекрасно понимать, что значит та или иная временная метка.
👍32👌1
zaninpz1.pdf
1.1 MB
Я просто оставлю это здесь и даже не буду подробно комментировать, так как далек от нынешнего высшего образования.
Но в наши времена сей опус с трудом потянул бы на курсовую, а тут как-никак выпускная работа (читай диплом).
И если теперь для дипломной работы достаточно просто поднять OpenVPN на двух узлах, то становится печально от такого уровня "образования".
Но в наши времена сей опус с трудом потянул бы на курсовую, а тут как-никак выпускная работа (читай диплом).
И если теперь для дипломной работы достаточно просто поднять OpenVPN на двух узлах, то становится печально от такого уровня "образования".
😱25👍8🤔6👀3
erid: LjN8KQY2w
Практический семинар для системных администраторов
Расширьте свои знания на открытом уроке «LVM: снапшоты, перенос данных, надежное хранение» от OTUS
📅 Занятие состоится 27 ноября в 20:00 мск и будет приурочено к старту курса «Administrator Linux. Professional»
🔥 Преподаватель Андрей Буранов — системный администратор в VK, работает с операционной системой Linux более 7 лет
Открытый урок — это отличная возможность бесплатно протестировать формат обучения и задать преподавателю любые вопросы в режиме реального времени. После урока вы сможете стать студентом курса в рассрочку
Регистрируйтесь на мероприятие прямо сейчас: https://otus.pw/cYrV/
На сайте вы также можете пройти короткое тестирование и узнать насколько вы соответствуете требованиям рынка
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Практический семинар для системных администраторов
Расширьте свои знания на открытом уроке «LVM: снапшоты, перенос данных, надежное хранение» от OTUS
📅 Занятие состоится 27 ноября в 20:00 мск и будет приурочено к старту курса «Administrator Linux. Professional»
🔥 Преподаватель Андрей Буранов — системный администратор в VK, работает с операционной системой Linux более 7 лет
Открытый урок — это отличная возможность бесплатно протестировать формат обучения и задать преподавателю любые вопросы в режиме реального времени. После урока вы сможете стать студентом курса в рассрочку
Регистрируйтесь на мероприятие прямо сейчас: https://otus.pw/cYrV/
На сайте вы также можете пройти короткое тестирование и узнать насколько вы соответствуете требованиям рынка
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
👎3👍2
Использование команды ip в Linux
Многие системные администраторы знали и использовали команду ifconfig, но теперь она объявлена устаревшей и вместо нее предлагаются иные инструменты. Один из них – команда ip, работу с которой мы сегодня рассмотрим.
Думаю, многим знакома команда просмотра IP адресов узла:
Но это сокращенная запись от:
Также можно использовать более короткую:
Используя полный вид записи, вы можете уточнить вывод команды, например, посмотреть адрес только у интересующего интерфейса:
Чтобы посмотреть только IPv4 или IPv6 адреса используйте дополнительные ключи -4 или -6
При помощи ip можно не только смотреть IP-адреса, но и управлять ими, так чтобы добавить адрес на интерфейс используйте:
Для удаления:
Также вы можете управлять состоянием самого интерфейса:
или
Кроме этого, команда ip позволяет работать с маршрутами, для просмотра таблицы маршрутизации достаточно выполнить:
или
Для ограничения вывода протоколами IPv4 или IPv6 также можете использовать ключи -4 или -6
При необходимости мы можем легко добавить или удалить маршрут командами:
и
При этом следует помнить, что добавленные таким образом маршруты не сохраняются при перезагрузке системы.
Многие системные администраторы знали и использовали команду ifconfig, но теперь она объявлена устаревшей и вместо нее предлагаются иные инструменты. Один из них – команда ip, работу с которой мы сегодня рассмотрим.
Думаю, многим знакома команда просмотра IP адресов узла:
ip a
Но это сокращенная запись от:
ip address showТакже можно использовать более короткую:
ip addr show
Используя полный вид записи, вы можете уточнить вывод команды, например, посмотреть адрес только у интересующего интерфейса:
ip addr show ens33Чтобы посмотреть только IPv4 или IPv6 адреса используйте дополнительные ключи -4 или -6
ip -4 addr show ens33При помощи ip можно не только смотреть IP-адреса, но и управлять ими, так чтобы добавить адрес на интерфейс используйте:
ip addr add 192.168.233.144/24 dev ens33
Для удаления:
ip addr del 192.168.233.144/24 dev ens33Также вы можете управлять состоянием самого интерфейса:
ip link set ens33 up
или
ip link set ens33 downКроме этого, команда ip позволяет работать с маршрутами, для просмотра таблицы маршрутизации достаточно выполнить:
ip r или
ip route
Для ограничения вывода протоколами IPv4 или IPv6 также можете использовать ключи -4 или -6
При необходимости мы можем легко добавить или удалить маршрут командами:
ip route add 192.168.233.0/24 dev ens33 metric 100и
ip route delete 192.168.233.0/24 dev ens33При этом следует помнить, что добавленные таким образом маршруты не сохраняются при перезагрузке системы.
👍48👀2
Демилитаризованная зона (DMZ) в современных сетях
Концепция DMZ известна давно, предполагалось, что это будет отдельный сегмент сети, отделенный брандмауэрами как от внешней, так и от внутренних сетей, и в нем будут размещены потенциально небезопасные сервисы.
Т.е. мы собирали в таком сегменте все сервисы, имеющие доступ из внешнего мира, и ограничивали их собственной подсетью, серьезно ограничив или вообще запретив возможность доступа к внутренней сети.
Для узлов локальной сети все узлы DMZ также рассматривались как внешние, со всеми вытекающими выводами в сфере безопасности.
Данный подход позволял в случае взлома или компрометации внешнего сервиса ограничить злоумышленника рамками DMZ и избежать их проникновения за периметр основной сети предприятия.
В целом такой подход работает и сегодня для классических служб, таких как веб-сервер или электронная почта. Помещая такие сервера в отдельный сегмент и закрыв их брандмауэром как от внешней, так и внутренней сети мы повышаем как безопасность внутри периметра, так и безопасность самих вынесенных в DMZ сервисов.
Но современные реалии вносят новые угрозы. Например, понятие периметра сегодня оказалось серьезно размыто и далеко не каждая внутренняя сеть может считаться безопасной.
Причин тому несколько. Начиная с собственных устройств сотрудников, которые они используют в рабочем процессе (чаще всего телефоны) и которые имеют доступ к сети предприятия и заканчивая средствами удаленного доступа, которые используются не только сотрудниками, но и подрядчиками и партнерами.
Все это приводит к тому, что внутренняя сеть перестает быть безопасным и доверенным местом, поэтому политика нормально открытого брандмауэра внутри таких сетей перестает быть приемлемой.
Можно, конечно, настраивать брандмауэр на каждом сервере отдельно, но это утомительно и всегда есть возможность что-то упустить. Поэтому более интересной является мысль вынести внутренние сервера в отдельную DMZ и тем самым поместить их в доверенную среду, которую затем можно просто закрыть от внутренней сети межсетевым экраном.
Получается, как бы немного наоборот. Если классическая DMZ изолировала от доверенной локальной сети потенциально небезопасные узлы, то в нашем случае DMZ защищает сервера от потенциальных угроз из внутренней сети.
В принципе данный подход уже давно используется там, где работают с конфиденциальной и секретной информацией, когда содержащие такие данные узлы выносят в изолированные участки сети с ограниченным доступом.
Еще одна серьезная угроза – это удаленщики, явление в последние годы массовое и практически неконтролируемое. Потому как вы не можете сказать кто именно сейчас на том конце соединения: сам сотрудник или его малолетний ребенок, а может он вообще забыл ноутбук где-нибудь в кафе.
И все что защищает VPN – это только сам канал доступа, от некорректных действий со стороны пользователя это не спасет. Поэтому мы последние несколько лет практикуем дополнительные DMZ именно для VPN-пользователей.
В этом случае все удаленщики также помещаются в отдельный сегмент, который изолирован как от внешней, так и от внутренней сети, а доступ к необходимым сервисам осуществляется посредством проброса портов или обратным проксированием.
При этом никаких сервисов в этой зоне быть не должно, только удаленщики и только средства доступа к необходимым им сервисам внутри сети или в отдельных DMZ.
Таким образом сегодня понятие DMZ серьезно расширилось и теперь не просто предусматривает некую отдельную подсеть для потенциально ненадежных сервисов, а подразумевает разделение сети на сегменты с разным уровнем безопасности и доверия, совершенно безотносительного того, являются помещенные в DMZ сервисы внешними или внутренними.
А в ряде случаев и вовсе не предполагает размещение там каких-либо сервисов, используя DMZ для изоляции ненадежных пользователей.
Концепция DMZ известна давно, предполагалось, что это будет отдельный сегмент сети, отделенный брандмауэрами как от внешней, так и от внутренних сетей, и в нем будут размещены потенциально небезопасные сервисы.
Т.е. мы собирали в таком сегменте все сервисы, имеющие доступ из внешнего мира, и ограничивали их собственной подсетью, серьезно ограничив или вообще запретив возможность доступа к внутренней сети.
Для узлов локальной сети все узлы DMZ также рассматривались как внешние, со всеми вытекающими выводами в сфере безопасности.
Данный подход позволял в случае взлома или компрометации внешнего сервиса ограничить злоумышленника рамками DMZ и избежать их проникновения за периметр основной сети предприятия.
В целом такой подход работает и сегодня для классических служб, таких как веб-сервер или электронная почта. Помещая такие сервера в отдельный сегмент и закрыв их брандмауэром как от внешней, так и внутренней сети мы повышаем как безопасность внутри периметра, так и безопасность самих вынесенных в DMZ сервисов.
Но современные реалии вносят новые угрозы. Например, понятие периметра сегодня оказалось серьезно размыто и далеко не каждая внутренняя сеть может считаться безопасной.
Причин тому несколько. Начиная с собственных устройств сотрудников, которые они используют в рабочем процессе (чаще всего телефоны) и которые имеют доступ к сети предприятия и заканчивая средствами удаленного доступа, которые используются не только сотрудниками, но и подрядчиками и партнерами.
Все это приводит к тому, что внутренняя сеть перестает быть безопасным и доверенным местом, поэтому политика нормально открытого брандмауэра внутри таких сетей перестает быть приемлемой.
Можно, конечно, настраивать брандмауэр на каждом сервере отдельно, но это утомительно и всегда есть возможность что-то упустить. Поэтому более интересной является мысль вынести внутренние сервера в отдельную DMZ и тем самым поместить их в доверенную среду, которую затем можно просто закрыть от внутренней сети межсетевым экраном.
Получается, как бы немного наоборот. Если классическая DMZ изолировала от доверенной локальной сети потенциально небезопасные узлы, то в нашем случае DMZ защищает сервера от потенциальных угроз из внутренней сети.
В принципе данный подход уже давно используется там, где работают с конфиденциальной и секретной информацией, когда содержащие такие данные узлы выносят в изолированные участки сети с ограниченным доступом.
Еще одна серьезная угроза – это удаленщики, явление в последние годы массовое и практически неконтролируемое. Потому как вы не можете сказать кто именно сейчас на том конце соединения: сам сотрудник или его малолетний ребенок, а может он вообще забыл ноутбук где-нибудь в кафе.
И все что защищает VPN – это только сам канал доступа, от некорректных действий со стороны пользователя это не спасет. Поэтому мы последние несколько лет практикуем дополнительные DMZ именно для VPN-пользователей.
В этом случае все удаленщики также помещаются в отдельный сегмент, который изолирован как от внешней, так и от внутренней сети, а доступ к необходимым сервисам осуществляется посредством проброса портов или обратным проксированием.
При этом никаких сервисов в этой зоне быть не должно, только удаленщики и только средства доступа к необходимым им сервисам внутри сети или в отдельных DMZ.
Таким образом сегодня понятие DMZ серьезно расширилось и теперь не просто предусматривает некую отдельную подсеть для потенциально ненадежных сервисов, а подразумевает разделение сети на сегменты с разным уровнем безопасности и доверия, совершенно безотносительного того, являются помещенные в DMZ сервисы внешними или внутренними.
А в ряде случаев и вовсе не предполагает размещение там каких-либо сервисов, используя DMZ для изоляции ненадежных пользователей.
👍50🔥2👎1
Веселые картинки
Сегодня в обсуждения один из читателей притащил ссылку на «хороший материал по сегментации» со ссылкой на многим известный репозиторий на гитхабе: https://github.com/sergiomarotco/Network-segmentation-cheat-sheet
К сожалению, я не могу считать данный материал хорошим и тем более рекомендовать его, хотя автор и ссылается на некие «лучшие практики».
Почему? Начнем издалека, с принципов построения обучающих материалов. Хороший обучающий материал, тем более схема или диаграмма должна быть способна сразу донести до обучаемого основные принципы и ключевые моменты изучаемой темы.
Ничего лишнего, никаких ненужных подробностей на схеме быть не должно, они только размывают внимание на второстепенные вещи, путают и вызывают лишние вопросы.
Вместо этого нас встречает перегруженная значками и связями схема, которая ничего не поясняет, а только еще больше запутывает. Сразу возникает масса вопросов, причем абсолютно к теме сегментации не относящихся.
В целом, человек немного «теме» со схемами первых уровней за пять-десять минут вождения по ним пальцем разберется и здравое зерно там есть. Но для начинающего это будет просто темный лес: ничего не понятно, но очень интересно. Еще хуже если последуют попытки слепого копирования.
Но все можно было сделать гораздо проще, убрать все эти ненужные подробности и связи, оставив только самые широкие мазки: вот у нас продуктовые сервера, вот поддержка продуктовой части, вот пользовательская часть, вот поддержка пользовательской части, вот управление, вот сетевое оборудование, вот DMZ.
Ну и хорошую пояснительную записку, поясняющую что именно сделано, для чего и почему.
А текущие схемы сильно напоминают мне казуальные игрушки, где нужно копать-строить да отбиваться от толп монстров, где каждая следующая толпа сильнее предыдущей.
А все эти линии напоминают производственные цепочки, которые могут быть неоптимальны и запутаны, но так «исторически сложились». И вообще переделать пока никак нельзя, а то не отобьемся.
И автор схем только подливает масла в огонь, указывая в описании к первому уровню что вам понадобится больше средств защиты информации или потребуется переход на второй уровень.
Знакомо? Чтобы отбиваться от монстров вам нужно все больше и больше стреляющих башен, но башни стоят ресурсов, их надо где-то строить, и монстры начинают сносить их на ура. Хочешь - не хочешь, а уровень придется повышать.
Причем складывается такое впечатление, что автор схем отринул реальность и занялся сегментацией ради сегментации. Уже на третьем уровне он вводит системы обнаружения инцидентов и реагирования на них, вскользь упомянув «что вам понадобится штат 10-20 человек безопасников».
Серьезно? Организации такого уровня, где риски ИБ выходят на уровень операционных рисков явно не будут искать схемы по гитам и на этом можно бы было закончить. Но фантазия автора устремляется только вперед.
Хотя для простого пользователя все эти многочисленные возникшие объекты с непонятными аббревиатурами ничем не будут отличаться от генератора маны, школы магов и чего там еще надо построить для того, чтобы башни начали стрелять электричеством.
Ну и последняя схема – просто апофеоз:
Теперь злоумышленник не сможет атаковать производственную сеть, поскольку теперь потенциально скомпрометированная рабочая станция в корпоративной сети принципиально не имеет доступа к производственной сети. Связанные проблемы:
Отдельные рабочие станции для доступа к производственной сети – да, теперь у вас на рабочем столе будет 2 компьютера;
Да, именно к этому бизнес и стремился… И деньги на него, наверное, с неба падают.
Вопросы разумной достаточности здесь не поднимаются в принципе. Автор рассматривает сегментацию с позиции типичного гика в вакууме. Хотя для того, чтобы закрыть в садовом домике две лопаты и ржавые грабли достаточно замка за 100 рублей и ставить сейфовую дверь с укреплением коробки там явно излишне.
В общем материал забавный, красивый. Но практической пользы – близко к нулю.
Сегодня в обсуждения один из читателей притащил ссылку на «хороший материал по сегментации» со ссылкой на многим известный репозиторий на гитхабе: https://github.com/sergiomarotco/Network-segmentation-cheat-sheet
К сожалению, я не могу считать данный материал хорошим и тем более рекомендовать его, хотя автор и ссылается на некие «лучшие практики».
Почему? Начнем издалека, с принципов построения обучающих материалов. Хороший обучающий материал, тем более схема или диаграмма должна быть способна сразу донести до обучаемого основные принципы и ключевые моменты изучаемой темы.
Ничего лишнего, никаких ненужных подробностей на схеме быть не должно, они только размывают внимание на второстепенные вещи, путают и вызывают лишние вопросы.
Вместо этого нас встречает перегруженная значками и связями схема, которая ничего не поясняет, а только еще больше запутывает. Сразу возникает масса вопросов, причем абсолютно к теме сегментации не относящихся.
В целом, человек немного «теме» со схемами первых уровней за пять-десять минут вождения по ним пальцем разберется и здравое зерно там есть. Но для начинающего это будет просто темный лес: ничего не понятно, но очень интересно. Еще хуже если последуют попытки слепого копирования.
Но все можно было сделать гораздо проще, убрать все эти ненужные подробности и связи, оставив только самые широкие мазки: вот у нас продуктовые сервера, вот поддержка продуктовой части, вот пользовательская часть, вот поддержка пользовательской части, вот управление, вот сетевое оборудование, вот DMZ.
Ну и хорошую пояснительную записку, поясняющую что именно сделано, для чего и почему.
А текущие схемы сильно напоминают мне казуальные игрушки, где нужно копать-строить да отбиваться от толп монстров, где каждая следующая толпа сильнее предыдущей.
А все эти линии напоминают производственные цепочки, которые могут быть неоптимальны и запутаны, но так «исторически сложились». И вообще переделать пока никак нельзя, а то не отобьемся.
И автор схем только подливает масла в огонь, указывая в описании к первому уровню что вам понадобится больше средств защиты информации или потребуется переход на второй уровень.
Знакомо? Чтобы отбиваться от монстров вам нужно все больше и больше стреляющих башен, но башни стоят ресурсов, их надо где-то строить, и монстры начинают сносить их на ура. Хочешь - не хочешь, а уровень придется повышать.
Причем складывается такое впечатление, что автор схем отринул реальность и занялся сегментацией ради сегментации. Уже на третьем уровне он вводит системы обнаружения инцидентов и реагирования на них, вскользь упомянув «что вам понадобится штат 10-20 человек безопасников».
Серьезно? Организации такого уровня, где риски ИБ выходят на уровень операционных рисков явно не будут искать схемы по гитам и на этом можно бы было закончить. Но фантазия автора устремляется только вперед.
Хотя для простого пользователя все эти многочисленные возникшие объекты с непонятными аббревиатурами ничем не будут отличаться от генератора маны, школы магов и чего там еще надо построить для того, чтобы башни начали стрелять электричеством.
Ну и последняя схема – просто апофеоз:
Теперь злоумышленник не сможет атаковать производственную сеть, поскольку теперь потенциально скомпрометированная рабочая станция в корпоративной сети принципиально не имеет доступа к производственной сети. Связанные проблемы:
Отдельные рабочие станции для доступа к производственной сети – да, теперь у вас на рабочем столе будет 2 компьютера;
Да, именно к этому бизнес и стремился… И деньги на него, наверное, с неба падают.
Вопросы разумной достаточности здесь не поднимаются в принципе. Автор рассматривает сегментацию с позиции типичного гика в вакууме. Хотя для того, чтобы закрыть в садовом домике две лопаты и ржавые грабли достаточно замка за 100 рублей и ставить сейфовую дверь с укреплением коробки там явно излишне.
В общем материал забавный, красивый. Но практической пользы – близко к нулю.
👍9😁9🤔2🤝1
IP-калькулятор в консоли
Любой администратор рано или поздно сталкивается с необходимостью рассчитать ту или иную сеть по количеству хостов или маске. Обычно для этих целей используются IP-калькуляторы, чаше всего в виде онлайн сервисов.
Но для любителей работы в консоли и не только есть прекрасная альтернатива в виде консольного приложения, оно есть в стандартных репозиториях и для его установки просто введите:
Использовать его тоже очень просто, достаточно указать адрес и маску. Маску можно указывать всеми доступными вариантами:
Также вы можете сразу расширить или сузить сеть и сразу увидеть в какую сеть большего размера попадет ваша подсеть или, наоборот, на какие подсети она будет разделена:
Еще одна часто встречающаяся задача – нарезать некоторое адресное пространство на несколько подсетей с заданным количеством хостов. Все просто, указываем сеть или адрес нужной сети и перечисляем нужные пулы по количеству хостов:
Результат можно посмотреть на картинке ниже. Калькулятор поделил сеть на несколько подсетей с наиболее подходящим количеством хостов.
Кроме обычной информации калькулятор таже выводит все значения в двоичном виде, что довольно ценно для начинающих, так как позволяет собственными глазами увидеть, что такое маска и почему при указанном значении маски максимальные и минимальные адреса сети будут именно такими, а не другими.
Более редкая, но тоже нужная задача – деагрегация диапазона адресов. Это если нам нужно разложить некое адресное пространство на набор сетей. Задача не самая простая, но калькулятор успешно справляется и с ней, просто укажите диапазон адресов, остальное он все сделает сам.
Никакого заумного синтаксиса, никаких ключей. Все просто, понятно, наглядно. И не надо никаких онлайн сервисов, достаточно просто запустить терминал.
Любой администратор рано или поздно сталкивается с необходимостью рассчитать ту или иную сеть по количеству хостов или маске. Обычно для этих целей используются IP-калькуляторы, чаше всего в виде онлайн сервисов.
Но для любителей работы в консоли и не только есть прекрасная альтернатива в виде консольного приложения, оно есть в стандартных репозиториях и для его установки просто введите:
apt install ipcalcИспользовать его тоже очень просто, достаточно указать адрес и маску. Маску можно указывать всеми доступными вариантами:
ipcalc 192.168.2.52/24ipcalc 192.168.2.52/255.255.255.0ipcalc 192.168.2.52 255.255.255.0Также вы можете сразу расширить или сузить сеть и сразу увидеть в какую сеть большего размера попадет ваша подсеть или, наоборот, на какие подсети она будет разделена:
ipcalc 192.168.2.52 /24 /22ipcalc 192.168.2.52 /24 /25Еще одна часто встречающаяся задача – нарезать некоторое адресное пространство на несколько подсетей с заданным количеством хостов. Все просто, указываем сеть или адрес нужной сети и перечисляем нужные пулы по количеству хостов:
ipcalc 10.8.8.1 -s 120 55 25Результат можно посмотреть на картинке ниже. Калькулятор поделил сеть на несколько подсетей с наиболее подходящим количеством хостов.
Кроме обычной информации калькулятор таже выводит все значения в двоичном виде, что довольно ценно для начинающих, так как позволяет собственными глазами увидеть, что такое маска и почему при указанном значении маски максимальные и минимальные адреса сети будут именно такими, а не другими.
Более редкая, но тоже нужная задача – деагрегация диапазона адресов. Это если нам нужно разложить некое адресное пространство на набор сетей. Задача не самая простая, но калькулятор успешно справляется и с ней, просто укажите диапазон адресов, остальное он все сделает сам.
ipcalc 10.8.8.125 – 10.9.2.251Никакого заумного синтаксиса, никаких ключей. Все просто, понятно, наглядно. И не надо никаких онлайн сервисов, достаточно просто запустить терминал.
👍62⚡1❤1
Про успешный успех
Есть в наши дни такое развлечение: рассказывать про успешный успех. При этом хватает и рассказчиков, и слушателей.
Одни самозабвенно рассказывают, как они прорывались сквозь тернии к звездам, преодолевали, превозмогали и теперь вот такие успешные купаются в лучах заслуженной славы.
Есть и иная разновидность жанра – рассказывать про то, как вопреки всему профукали все полимеры, но неоднократно подчеркивая при этом, что получили при этом большой опыт и готовы поделиться им со слушателями.
При этом и те и другие порываются учить и редко делают это бесплатно.
В общем, после очередной встречи с очередными учителями успешного успеха мы немного задумались по этому поводу и пришли к некоторым выводам, которые могут показаться интересными нашим читателям.
Итак, что такое успех проекта и на основании каких показателей можно сделать такие выводы?
Начнем с очевидного, если проект уткнулся лицом в асфальт еще не достигнув финиша, это говорит только об одном – вы полезли не в свое дело, туда, где вы ничего не знаете и не умеете и вам тупо не хватило ума понять куда вы лезете.
Никакого ценного опыта там нет, разве что только наглядный пример как делать не надо.
А вот следует ли считать проект, дошедший до финиша успешным – это большой вопрос.
С одной стороны, все формальные требования выполнены? Выполнены. Акты подписаны? Подписаны. Деньги получены? Получены. Ну так, наверное, все хорошо?
Наверное. И если рассматривать сугубо финансовую сторону вопроса. На самом деле для проекта все только начинается. Мы же не судим об успешности человека в момент его рождения? А почему для проекта должны быть исключения?
На наш взгляд существует единственная достоверная метрика успешности проекта – все реализованные в нем разработки или большая их часть используются в повседневной деятельности предприятия и отказ от них будет связан с реальным ухудшением производственных процессов.
Только в этом случае заказчик будет удовлетворен сотрудничеством и нацелен его продолжать.
Иначе он может даже ничего не сказать, но просто не будет использовать то, за что отданы деньги и больше не станет к вам обращаться.
Все это справедливо и для внутренних проектов. Если от того, что вы так усердно внедряли и на что тратили деньги предприятия нет реального выхлопа, то вам могут в целом ничего не сказать, но поставят там, где надо пометочку и именно эта пометочка может стать реальной помехой для дальнейшего карьерного роста.
Как показывает наша практика, практически все успешные проекты развивались постепенно, по мере возникновения реальных проблем и их решения. В этом случае все изменения вносились органично и быстро врастали в бизнес-процессы предприятия, формируя некоторые внутренние стандарты.
И, наоборот, попытка быстро внедрить сложную автоматизацию редко заканчивается успехом, а чаще всего даст возможность успешно закончить проект тем, кто придет вслед за вами. И сможет-таки, за дополнительные деньги подружить все что вы успели наворотить с реальными бизнес-процессами.
Поэтому, когда мне рассказывают истории успешного успеха как за несколько месяцев автоматизировали с нуля чего-то там, то я могу сказать только одно – не верю. Либо на самом деле все было совсем не так.
Нельзя быстро и не ломая бизнес-процессов сделать так, что там, где сегодня компьютер первый раз увидели через полгода будет многоуровневый учет и отчетность, обмены и интеграции, и полный контроль с автоматизацией.
Нет, иногда можно, но только через слом всего и вся и преодоление противодействия на самых разных уровнях. Работающий бизнес на такое может решиться либо сугубо сдуру, либо от безысходности.
Либо мы просто формально внедряем то, чем просто не будут пользоваться. Со всеми вытекающими в последствии.
Поэтому, слушая рассказы про успешный успех всегда помните, что это художественный жанр, а успешность любого проекта можно оценить только на достаточно большом временном отрезке. И основной критерий успеха – это практика. Если то, что вы сделали используют – значит проект успешен.
Есть в наши дни такое развлечение: рассказывать про успешный успех. При этом хватает и рассказчиков, и слушателей.
Одни самозабвенно рассказывают, как они прорывались сквозь тернии к звездам, преодолевали, превозмогали и теперь вот такие успешные купаются в лучах заслуженной славы.
Есть и иная разновидность жанра – рассказывать про то, как вопреки всему профукали все полимеры, но неоднократно подчеркивая при этом, что получили при этом большой опыт и готовы поделиться им со слушателями.
При этом и те и другие порываются учить и редко делают это бесплатно.
В общем, после очередной встречи с очередными учителями успешного успеха мы немного задумались по этому поводу и пришли к некоторым выводам, которые могут показаться интересными нашим читателям.
Итак, что такое успех проекта и на основании каких показателей можно сделать такие выводы?
Начнем с очевидного, если проект уткнулся лицом в асфальт еще не достигнув финиша, это говорит только об одном – вы полезли не в свое дело, туда, где вы ничего не знаете и не умеете и вам тупо не хватило ума понять куда вы лезете.
Никакого ценного опыта там нет, разве что только наглядный пример как делать не надо.
А вот следует ли считать проект, дошедший до финиша успешным – это большой вопрос.
С одной стороны, все формальные требования выполнены? Выполнены. Акты подписаны? Подписаны. Деньги получены? Получены. Ну так, наверное, все хорошо?
Наверное. И если рассматривать сугубо финансовую сторону вопроса. На самом деле для проекта все только начинается. Мы же не судим об успешности человека в момент его рождения? А почему для проекта должны быть исключения?
На наш взгляд существует единственная достоверная метрика успешности проекта – все реализованные в нем разработки или большая их часть используются в повседневной деятельности предприятия и отказ от них будет связан с реальным ухудшением производственных процессов.
Только в этом случае заказчик будет удовлетворен сотрудничеством и нацелен его продолжать.
Иначе он может даже ничего не сказать, но просто не будет использовать то, за что отданы деньги и больше не станет к вам обращаться.
Все это справедливо и для внутренних проектов. Если от того, что вы так усердно внедряли и на что тратили деньги предприятия нет реального выхлопа, то вам могут в целом ничего не сказать, но поставят там, где надо пометочку и именно эта пометочка может стать реальной помехой для дальнейшего карьерного роста.
Как показывает наша практика, практически все успешные проекты развивались постепенно, по мере возникновения реальных проблем и их решения. В этом случае все изменения вносились органично и быстро врастали в бизнес-процессы предприятия, формируя некоторые внутренние стандарты.
И, наоборот, попытка быстро внедрить сложную автоматизацию редко заканчивается успехом, а чаще всего даст возможность успешно закончить проект тем, кто придет вслед за вами. И сможет-таки, за дополнительные деньги подружить все что вы успели наворотить с реальными бизнес-процессами.
Поэтому, когда мне рассказывают истории успешного успеха как за несколько месяцев автоматизировали с нуля чего-то там, то я могу сказать только одно – не верю. Либо на самом деле все было совсем не так.
Нельзя быстро и не ломая бизнес-процессов сделать так, что там, где сегодня компьютер первый раз увидели через полгода будет многоуровневый учет и отчетность, обмены и интеграции, и полный контроль с автоматизацией.
Нет, иногда можно, но только через слом всего и вся и преодоление противодействия на самых разных уровнях. Работающий бизнес на такое может решиться либо сугубо сдуру, либо от безысходности.
Либо мы просто формально внедряем то, чем просто не будут пользоваться. Со всеми вытекающими в последствии.
Поэтому, слушая рассказы про успешный успех всегда помните, что это художественный жанр, а успешность любого проекта можно оценить только на достаточно большом временном отрезке. И основной критерий успеха – это практика. Если то, что вы сделали используют – значит проект успешен.
👍43🔥6👎3
Войти в айти
Был сегодня в гостях у знакомых и сразу, чуть ли не с порога первый вопрос – как сейчас лучше войти в айти. Ну да понятно, у них сын весной школу будет заканчивать и вопрос выбора будущей профессии стоит остро.
Посидел, попил чая, с будущим коллегой побеседовал и не увидел у него вообще ни желания, ни интереса, ни каких бы там ни было способностей к этому делу.
Спрашиваю, а зачем в айти то, не самая простая отрасль, как никак, да еще и постоянного самообразования требует.
На что услышал, мол ладно тебе, все равно у айтишников самые высокие зарплаты и работают в тепле и уюте, сидя за компьютером, а еще можно удаленно из дома работать.
В целом они в чем-то правы и даже у начинающего айтишника зарплата если не будет самой высокой по рынку, то все равно будет выше, чем у начинающих в других отраслях.
И если с нашей, отраслевой точки зрения, зарплаты отдельных юных падаванов невелики, то с точки зрения широких народных масс – они достаточно высоки, особенно за то, что эти самые айтишники сидят в тепле и ничего не делают.
Поэтому можно говорить, что в обществе давно сложилось понимание айти как некой синекуры, куда надо только попасть, а потом катайся как сыр в масле. На самом деле все конечно сложнее, но мнение уже сложилось.
Масла в огонь подбавляют и всевозможные курсы, и даже государственные программы по переквалификации самых широких народных масс населения в айтишников.
Государство понять можно, с нынешними темпами цифровизации и импортозамещения ему срочно нужны специалисты нижнего звена, в достаточном для их массового использования количестве.
Плюс айти всячески популяризуется у молодого поколения, о чем мы только что писали выше.
Нынешние высокие заработные платы в IT обусловлены двумя вещами: дефицитом специалистов и достаточно высокой добавочной стоимостью, таким специалистом производимой.
Но и трудятся такие специалисты преимущественно в коммерческой сфере, где никто терпеть лентяев и дураков не будет: или ты работаешь и получаешь нормальные деньги или идешь на улицу.
Войти в такое айти просто так сложно, какие бы дипломы и корочки у тебя не были. В коммерции на диплом смотрят в последнюю очередь. Ты или умеешь и делаешь, либо не умеешь и проходишь мимо и неважно кто-то по специальности: программист или ветеринар.
А вот в госсекторе все по-иному, там можно годами ничего не делать, просто имитируя рабочий процесс и красиво отчитываясь наверх, плюс присутствуют достаточно специфичные взаимоотношения, которые лучше всего характеризуются поговоркой: «я начальник – ты дурак, ты начальник – я дурак».
Нормальные специалисты в госсектор не спешат. Частично из-за невысоких по отраслевым меркам зарплат, а частично из-за специфики рабочих отношений (скажем так). А кто и прибивается – так ненадолго, ну или в случае, если больше никуда не берут.
Поэтому именно государству сегодня выгодно выбросить на рынок большое количество начинающих айтишников. Которые, прекрасно понимая сами, что айтишники они «ненастоящие» не будут страдать излишними амбициями и пойдут туда, где тепло, светло и деньги платят, т.е. преимущественно в госсектор.
Хотя кто-то, возможно, и откроет в себе новые способности, но это будут именно штучные случаи. Аналогичный эффект даст и массовый приток молодежи на айти специальности. Появится обширный рынок молодых специалистов, хотя и невысокой квалификации.
А что это значит? А это значит, что уровень зарплаты в этом сегменте резко пойдет вниз, по-другому никак, если по рынку труда бегают стада молодых (и не очень) айтишников, желающих просто найти работу по специальности.
Повлияет ли это на уровень зарплат в отрасли в целом? Нет. Опытные специалисты как были, так и останутся востребованы. А вот существующий сейчас перекос, когда даже молодой и зеленый айтишник получает выше среднего – выправит.
А вообще история повторяется. В начале нулевых модно было быть юристом. И где сейчас все эти стада молодых юристов? А хороших что тогда, что сейчас приходится поискать и получают они более чем достойно.
Был сегодня в гостях у знакомых и сразу, чуть ли не с порога первый вопрос – как сейчас лучше войти в айти. Ну да понятно, у них сын весной школу будет заканчивать и вопрос выбора будущей профессии стоит остро.
Посидел, попил чая, с будущим коллегой побеседовал и не увидел у него вообще ни желания, ни интереса, ни каких бы там ни было способностей к этому делу.
Спрашиваю, а зачем в айти то, не самая простая отрасль, как никак, да еще и постоянного самообразования требует.
На что услышал, мол ладно тебе, все равно у айтишников самые высокие зарплаты и работают в тепле и уюте, сидя за компьютером, а еще можно удаленно из дома работать.
В целом они в чем-то правы и даже у начинающего айтишника зарплата если не будет самой высокой по рынку, то все равно будет выше, чем у начинающих в других отраслях.
И если с нашей, отраслевой точки зрения, зарплаты отдельных юных падаванов невелики, то с точки зрения широких народных масс – они достаточно высоки, особенно за то, что эти самые айтишники сидят в тепле и ничего не делают.
Поэтому можно говорить, что в обществе давно сложилось понимание айти как некой синекуры, куда надо только попасть, а потом катайся как сыр в масле. На самом деле все конечно сложнее, но мнение уже сложилось.
Масла в огонь подбавляют и всевозможные курсы, и даже государственные программы по переквалификации самых широких народных масс населения в айтишников.
Государство понять можно, с нынешними темпами цифровизации и импортозамещения ему срочно нужны специалисты нижнего звена, в достаточном для их массового использования количестве.
Плюс айти всячески популяризуется у молодого поколения, о чем мы только что писали выше.
Нынешние высокие заработные платы в IT обусловлены двумя вещами: дефицитом специалистов и достаточно высокой добавочной стоимостью, таким специалистом производимой.
Но и трудятся такие специалисты преимущественно в коммерческой сфере, где никто терпеть лентяев и дураков не будет: или ты работаешь и получаешь нормальные деньги или идешь на улицу.
Войти в такое айти просто так сложно, какие бы дипломы и корочки у тебя не были. В коммерции на диплом смотрят в последнюю очередь. Ты или умеешь и делаешь, либо не умеешь и проходишь мимо и неважно кто-то по специальности: программист или ветеринар.
А вот в госсекторе все по-иному, там можно годами ничего не делать, просто имитируя рабочий процесс и красиво отчитываясь наверх, плюс присутствуют достаточно специфичные взаимоотношения, которые лучше всего характеризуются поговоркой: «я начальник – ты дурак, ты начальник – я дурак».
Нормальные специалисты в госсектор не спешат. Частично из-за невысоких по отраслевым меркам зарплат, а частично из-за специфики рабочих отношений (скажем так). А кто и прибивается – так ненадолго, ну или в случае, если больше никуда не берут.
Поэтому именно государству сегодня выгодно выбросить на рынок большое количество начинающих айтишников. Которые, прекрасно понимая сами, что айтишники они «ненастоящие» не будут страдать излишними амбициями и пойдут туда, где тепло, светло и деньги платят, т.е. преимущественно в госсектор.
Хотя кто-то, возможно, и откроет в себе новые способности, но это будут именно штучные случаи. Аналогичный эффект даст и массовый приток молодежи на айти специальности. Появится обширный рынок молодых специалистов, хотя и невысокой квалификации.
А что это значит? А это значит, что уровень зарплаты в этом сегменте резко пойдет вниз, по-другому никак, если по рынку труда бегают стада молодых (и не очень) айтишников, желающих просто найти работу по специальности.
Повлияет ли это на уровень зарплат в отрасли в целом? Нет. Опытные специалисты как были, так и останутся востребованы. А вот существующий сейчас перекос, когда даже молодой и зеленый айтишник получает выше среднего – выправит.
А вообще история повторяется. В начале нулевых модно было быть юристом. И где сейчас все эти стада молодых юристов? А хороших что тогда, что сейчас приходится поискать и получают они более чем достойно.
👍41💯11❤9👎4😁1