ну вот про них я ролик не буду снимать.

Вооо про регулярки однозначно буду ждать отдельный видос, это лучше ни с чем не смешивать😉😁😊

Гуд👍

про регулярки я хз. пока это не укладывается в картину. т.е. если для новичка порядок загрузки, systemd, настрока сети, fhs, это всё выглядит полезным. а регулярки на старте не очень нужны

Про ssh много можно чего рассказать ssh-forwarding как делать и тд

Греп - главный инструмент администратора (с)

Очень часто (и это действительно так) приходится что-то фильтровать. Это может быть все что угодно - логи, конфиги, проекты, чужие наработки - набор данных в которых нужно что-то найти, stdout...  Умение пользоваться функционалом программ поиска\фильтрования может порой сэкономить вам кучу времени.

Какие инструменты используются для такой фильтрации?
1) cat - вывести файл на stdout
2) tail - вывести последие n строк из файла
3) less - утилита для просмотра stdout\файла с большим спектром возможностей. как пример - поиск строк по паттерну, введя вот такую конструкцию: /pattern для поиска по документу.
4) | - pipe, конвейер. ну, куда же без него. pipe - перенаправление стандартного потока вывода на стандартный поток ввода. В нашем случае это важный иструмент передачи данных между фильтрами.
5) ack - красочный поиск
6) grep - собственно самый главный инструмент. Тот самый инструмент, который и выполняет основную функцию фильтрования.

Искусство фильтрования кроется в умении объединять эти инструменты через pipe, правильной подаче входных данных на инструмент фильтрования и написание самих фильтров.

Что значит правильная подача данных?
Давайте сразу условимся, что работаем мы не с файлами на 50 строчек, а, например, с логами размером пару десятков гигабайт. Подача данных - это то, что мы отдадим фильтру на вход. Здесь есть несколько вариантов. Вариант первый - мы точно знаем что искать и вариант второй - мы не знаем, что на самом деле ищем. Второй случай - когда мы знаем, что-то происходило в такой-то период. За данный период у нас было несколько сотен тысяч записей. Что же делать? нужно пытаться подавать на вход фильтру ограниченное количество данных, а дальше смотреть глазами на получившийся вывод, стараясь понять какие записи в логах нам точно не нужны, снова фильтровать, исключая эти записи и так до тех пор, пока не останется вменяемо количество информации, которое можно анализировать.

Для подачи информации могут пригодиться команды cat, tail, head:

tail -n 1000 very_big_log | less
cat *.log | less

В первом случае мы подали ограниченное количество информации из конца файла, которую будем анализировать. Следующий этап - выкинуть лишние строчки из вывода. Кроме того, мы можем, например посчитать количество полученных строк после фильтрации, это можно сделать с помощью wc -l  Например, это нужно, чтобы посчитать кол-во ошибок одного типа или просто знать сколько строк вы нагрепали:

bzcat error.log.201803290* | grep -v 'upstream prematurely closed connection' | wc -l

Есть еще одно правило, которое гласит "don't pipe cats" - не пропускайте кошек через трубы. Правильнее (и менее трудозатратно) писать так:

bzgrep -v 'upstream prematurely closed connection' error.log.201803290* | less

И так дальше, убирая все больше и больше лишних строк, приходим к нужному результату. За отбрасывание ненужного паттерна отвечает ключ -v.

bzcat error.log.201803290* | grep -v 'upstream prematurely closed connection' | grep -v 'overlimit resources' |less

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

bzcat, bzgrep, bzless - для алгоритма bzip
zcat, zgrep, zless - для gzip.

Вот простой пример использованая grep для фильтрования веб-трафика (ловим пакеты от нужных url):

tcpdump -i eth1 -A|grep example.com

Одна из немаловажных вещей - умение использовать регулярные выражения при осуществлении поиска. Самый банальный пример - поиск логов в указанный период. для этого нам вновь поможет grep, но здесь о нас заранее позаботились. можно использовать ключ, а можно написать egrep\fgrep. И они такж могут быть скомбинированы с bz\z, например bzegrep.

egrep = grep -E
Interpret PATTERN as an extended regular expression
fgrep = grep -F
Interpret PATTERN as a list of fixed strings (instead of regular expressions), separated by newlines, any of which is to be matched.

Ищем ip-адреса в логах:

egrep '(46.200.110.19|13.104.34.97)' /var/log/nginx/...

#grep

Мощная тема если углубляться)

tail -n 1000 very_big_log | less
cat *.log | less

bzcat error.log.201803290* | grep -v 'upstream prematurely closed connection' | wc -l

bzgrep -v 'upstream prematurely closed connection' error.log.201803290* | less

bzcat error.log.201803290* | grep -v 'upstream prematurely closed connection' | grep -v 'overlimit resources' |less

bzcat, bzgrep, bzless - для алгоритма bzip
zcat, zgrep, zless - для gzip.

tcpdump -i eth1 -A|grep example.com

egrep '(46.200.110.19|13.104.34.97)' /var/log/nginx/...

О, кайф🙂👍

эта лекция есть. проблема в том что я ее читал в рамках курса, поэтому инфа не публичная

Ааа, а дорохо твои курсы стоють?)

Можно приватной ссылочкой поделитсья)

я свои курсы пока еще не веду. пока я читаю на готовых площадках - хакерю, отус. но думаю в этом направлении

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

Понял

А где можно прочитать о твоем бэкграунде или видео может есть?

Как правила с этих площадок потом на складчиках курсики и лежат кек)

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

хз. я как-то не задумывался. наверное только в резюме)

буду делать свои курсы, наверное тогда и напишу)

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

пакет nvidia-prime, хочу использовать, потому что никакие альтернативы дебиана не работают