Полезная для начинающих утилита с неприличным именем
Работая в консоли 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
👍15😁11❤6🤡2
Настраиваем Visual Studio Code для удаленной работы через SSH
Сегодня все чаще и чаще для конфигурационных файлов используются продвинутые текстовые форматы, такие как JSON или XML, имеющие строгий синтаксис и структуру.
Их применение облегчает программную обработку данных, но при этом они все еще остаются легко читаемыми человеком.
Однако работа с ними в привычных консольных редакторах имеет ряд неудобств, в частности связанных с соблюдением синтаксиса и формата разметки.
Поэтому гораздо удобнее использовать для этого специальные среды разработки, например, VS Code, тем более что он прекрасно умеет работать через SSH.
https://interface31.ru/tech_it/2024/05/nastraivaem-visual-studio-code-dlya-udalennoy-raboty-cherez-ssh.html
Сегодня все чаще и чаще для конфигурационных файлов используются продвинутые текстовые форматы, такие как JSON или XML, имеющие строгий синтаксис и структуру.
Их применение облегчает программную обработку данных, но при этом они все еще остаются легко читаемыми человеком.
Однако работа с ними в привычных консольных редакторах имеет ряд неудобств, в частности связанных с соблюдением синтаксиса и формата разметки.
Поэтому гораздо удобнее использовать для этого специальные среды разработки, например, VS Code, тем более что он прекрасно умеет работать через SSH.
https://interface31.ru/tech_it/2024/05/nastraivaem-visual-studio-code-dlya-udalennoy-raboty-cherez-ssh.html
👍25👨💻2
Прикупил себе обновку
Пользуясь поводом, прикупил пару недель назад себе обновку - Galaxy Watch Ultra 7. До этого я где-то в течении года искал на что поменять HONOR MagicWatch 2. В итоге приобрел Amazfit Balance, но все время меня преследовало ощущение, что поменял «шило на мыло».
А тут попались на глаза и, как говорится, зацепили. И есть чем. Внешний вид сразу выделяет часы из себе подобных. Материалы – титан и сапфировое стекло, несмотря на размеры часы на руке практически не ощущаются.
Размер. Часы крупные, как по горизонтальным размерам, так и в толщину, здесь на любителя, мне нравится. Кому-то могут оказаться велики. Кроме того, квадратная форма делает их визуально массивнее.
Экран – яркий, сочный, на солнце не слепнет. Если сравнивать с Amazfit Balance, то экран однозначно лучше. Хотя вроде все те же 480x480 при плотности пикселей в 327 ppi.
Циферблаты – просто отличные, достаточно проработанные и с весьма высокой степенью кастомизации. Настраивается буквально все, вы можете взять любой стандартный циферблат и вывести на него именно то, что нужно именно вам.
Теперь о внутреннем мире. Если сравнивать с HUAWEI / Amazfit – то это совсем другой уровень. Гораздо более продвинутая работа с датчиками и более полные и адекватные показания.
Скажем, только тут показатель стресса начал более-менее коррелировать с собственными ощущениями. Но не может быть уровень стресса низким после часа игры в футбол или высоким в то время, когда ты спокойный как удав лежишь в тенечке на даче.
Здесь – именно адекватно. Также гораздо более информативно интерпретируются показатели пульса, сна и т.д. и т.п.
Если те же HUAWEI / Amazfit мне просто писали про то, что сон у меня не очень, просто потому что не укладывается в некоторый шаблон, то Galaxy по накопленным данным выводят архетип сна и работают уже с ним.
После чего выясняется, что проблем особых и нет, просто кто-то спит так, кто-то по-другому. И в целом виден упор софта на персонализацию, когда все аналитические показатели строятся вокруг именно ваших средних значений.
А это уже интереснее и полезнее, потому как если какой-то показатель, даже оставаясь в пределах нормы, вдруг ощутимо отклонился от средних значений – то часы вам об этом сообщат.
Коммуникации тоже на высоте, практически любое действие с часов можно быстро и удобно перекинуть на телефон. Адекватно и обратное взаимодействие. Если вы прочитали уведомление на телефоне, часы его вам показывать больше не будут.
Также это первые на моей памяти часы (кроме «яблок»), которые имеют нормальный голосовой ввод. Они не требуют разговаривать медленно и по слогам, как со слабоумным, достаточно в обычном темпе надиктовать ответ на сообщение и часы быстро и без ошибок превратят речь в текст.
Из минусов – автономность. Если сильно не баловаться и не включать все датчики – автономность будет около 2,5 – 3 суток. Зарядка беспроводная, занимает примерно 2 часа.
С одной стороны это непривычно и несколько напрягает, с другой, если утром, пока умываешься – принимаешь душ - завтракаешь кинуть на зарядку, то проблемы в целом никакой не доставляет.
В общем, как и везде, свой набор компромиссов. Ну и не забываем, что часы, в том числе и электронные, особенно в ценовой категории от средней и выше, это не только и не сколько гаджет, но и аксессуар.
Пользуясь поводом, прикупил пару недель назад себе обновку - Galaxy Watch Ultra 7. До этого я где-то в течении года искал на что поменять HONOR MagicWatch 2. В итоге приобрел Amazfit Balance, но все время меня преследовало ощущение, что поменял «шило на мыло».
А тут попались на глаза и, как говорится, зацепили. И есть чем. Внешний вид сразу выделяет часы из себе подобных. Материалы – титан и сапфировое стекло, несмотря на размеры часы на руке практически не ощущаются.
Размер. Часы крупные, как по горизонтальным размерам, так и в толщину, здесь на любителя, мне нравится. Кому-то могут оказаться велики. Кроме того, квадратная форма делает их визуально массивнее.
Экран – яркий, сочный, на солнце не слепнет. Если сравнивать с Amazfit Balance, то экран однозначно лучше. Хотя вроде все те же 480x480 при плотности пикселей в 327 ppi.
Циферблаты – просто отличные, достаточно проработанные и с весьма высокой степенью кастомизации. Настраивается буквально все, вы можете взять любой стандартный циферблат и вывести на него именно то, что нужно именно вам.
Теперь о внутреннем мире. Если сравнивать с HUAWEI / Amazfit – то это совсем другой уровень. Гораздо более продвинутая работа с датчиками и более полные и адекватные показания.
Скажем, только тут показатель стресса начал более-менее коррелировать с собственными ощущениями. Но не может быть уровень стресса низким после часа игры в футбол или высоким в то время, когда ты спокойный как удав лежишь в тенечке на даче.
Здесь – именно адекватно. Также гораздо более информативно интерпретируются показатели пульса, сна и т.д. и т.п.
Если те же HUAWEI / Amazfit мне просто писали про то, что сон у меня не очень, просто потому что не укладывается в некоторый шаблон, то Galaxy по накопленным данным выводят архетип сна и работают уже с ним.
После чего выясняется, что проблем особых и нет, просто кто-то спит так, кто-то по-другому. И в целом виден упор софта на персонализацию, когда все аналитические показатели строятся вокруг именно ваших средних значений.
А это уже интереснее и полезнее, потому как если какой-то показатель, даже оставаясь в пределах нормы, вдруг ощутимо отклонился от средних значений – то часы вам об этом сообщат.
Коммуникации тоже на высоте, практически любое действие с часов можно быстро и удобно перекинуть на телефон. Адекватно и обратное взаимодействие. Если вы прочитали уведомление на телефоне, часы его вам показывать больше не будут.
Также это первые на моей памяти часы (кроме «яблок»), которые имеют нормальный голосовой ввод. Они не требуют разговаривать медленно и по слогам, как со слабоумным, достаточно в обычном темпе надиктовать ответ на сообщение и часы быстро и без ошибок превратят речь в текст.
Из минусов – автономность. Если сильно не баловаться и не включать все датчики – автономность будет около 2,5 – 3 суток. Зарядка беспроводная, занимает примерно 2 часа.
С одной стороны это непривычно и несколько напрягает, с другой, если утром, пока умываешься – принимаешь душ - завтракаешь кинуть на зарядку, то проблемы в целом никакой не доставляет.
В общем, как и везде, свой набор компромиссов. Ну и не забываем, что часы, в том числе и электронные, особенно в ценовой категории от средней и выше, это не только и не сколько гаджет, но и аксессуар.
👍29👎6❤5👀3⚡2
Система автономного обновления Linux
Многие пользователи и администраторы настольных систем на базе Linux заметили, что теперь обновления системы происходит при перезагрузке, совсем как в Windows.
Теперь мало просто запустить обновление, нужно еще обязательно перезагрузить систему и дождаться их установки. Кто-то воспринял данные новшества положительно, но многим это не понравилось, поэтому в данном материале мы постараемся подробно рассмотреть этот вопрос.
Сразу оговоримся, что речь в данном случае идет сугубо о системах с графической оболочкой.
Впервые проблема с обновлениями была сформулирована разработчиками Fedora еще в 2009 году. Тогда основной претензией было то, что обновления поставляются хаотично, не тестируются в комплексе и непонятны пользователям.
Действительно, если пользователю каждый день приходят обновления каких-то второстепенных библиотек, непонятного для него назначения, то это просто неуважение к рабочему времени пользователя.
Вторая проблема – это возможная работа пользователя в процессе обновления, Linux умеет заменять файлы уже запущенных приложений, но не все приложения умеют корректно обрабатывать такую ситуацию.
Тот же Firefox обнаружив обновление файлов программы попросит вас перезапустить браузер, но иные программы могут завершиться с ошибкой, зависнуть, вызвать темный экран и т.д. и т.п.
Несмотря на то, что процесс обновления продолжается пользователю может показаться, что система зависла или заглючила и он может принудительно ее перезагрузить.
Из этого вытекает третья проблема - выключение питания или перезагрузка системы во время обновления. Несмотря на то, что такое действие не приводит к действительно фатальным последствиям, но для обычного пользователя невозможность загрузить графическую оболочку равносильно отказу системы.
Чтобы решить все эти проблемы была разработана система автономного обновления, которая состоит из двух основных компонентов: пакетного менеджера и специальной службы systemd.
Теперь пакетный менеджер только скачивает обновления и уведомляет systemd об их наличии.
Но, как мы помним, дергать пользователя по пустякам – это очень плохо. Поэтому в зависимости от статуса обновления systemd может не спешить уведомлять пользователя об их наличии, а делать это, скажем, раз в неделю.
Также на пользователя не вываливается вся куча обновлений, а разбивается на метапакеты: обновление системы (23 пакета), обновление KDE (15 пакетов), обновление Firefox, LibreOffice и т.д., что делает процесс более понятным для пользователя.
Он видит пакеты обновления системы и пакеты обновления приложений, что гораздо удобнее чем длинный список непонятных пакетов.
При перезагрузке, если systemd видит скачанные обновления, то он загружает систему в специальный безопасный режим и начинает установку обновлений.
Если при этом произошло отключение питания, то при следующей загрузке systemd повторит эту процедуру. А если при установке обновлений произошли ошибки, то systemd откатит состояние системы.
При загрузке в нормальном режиме пользователь получит сообщение либо об успешном обновлении системы, либо об ошибке.
При этом возможно частичное обновление системы, если сбойный пакет не препятствует установке других обновлений.
Таким образом процесс обновления становится проще для пользователя и вписывается в его привычный пользовательский опыт, когда установка обновлений происходит при перезагрузке.
С технической стороны это делает систему более надежной и практически на 100% гарантирует ее загрузку в графическом режиме (за исключением действительно серьезных проблем).
Многие пользователи и администраторы настольных систем на базе Linux заметили, что теперь обновления системы происходит при перезагрузке, совсем как в Windows.
Теперь мало просто запустить обновление, нужно еще обязательно перезагрузить систему и дождаться их установки. Кто-то воспринял данные новшества положительно, но многим это не понравилось, поэтому в данном материале мы постараемся подробно рассмотреть этот вопрос.
Сразу оговоримся, что речь в данном случае идет сугубо о системах с графической оболочкой.
Впервые проблема с обновлениями была сформулирована разработчиками Fedora еще в 2009 году. Тогда основной претензией было то, что обновления поставляются хаотично, не тестируются в комплексе и непонятны пользователям.
Действительно, если пользователю каждый день приходят обновления каких-то второстепенных библиотек, непонятного для него назначения, то это просто неуважение к рабочему времени пользователя.
Вторая проблема – это возможная работа пользователя в процессе обновления, Linux умеет заменять файлы уже запущенных приложений, но не все приложения умеют корректно обрабатывать такую ситуацию.
Тот же Firefox обнаружив обновление файлов программы попросит вас перезапустить браузер, но иные программы могут завершиться с ошибкой, зависнуть, вызвать темный экран и т.д. и т.п.
Несмотря на то, что процесс обновления продолжается пользователю может показаться, что система зависла или заглючила и он может принудительно ее перезагрузить.
Из этого вытекает третья проблема - выключение питания или перезагрузка системы во время обновления. Несмотря на то, что такое действие не приводит к действительно фатальным последствиям, но для обычного пользователя невозможность загрузить графическую оболочку равносильно отказу системы.
Чтобы решить все эти проблемы была разработана система автономного обновления, которая состоит из двух основных компонентов: пакетного менеджера и специальной службы systemd.
Теперь пакетный менеджер только скачивает обновления и уведомляет systemd об их наличии.
Но, как мы помним, дергать пользователя по пустякам – это очень плохо. Поэтому в зависимости от статуса обновления systemd может не спешить уведомлять пользователя об их наличии, а делать это, скажем, раз в неделю.
Также на пользователя не вываливается вся куча обновлений, а разбивается на метапакеты: обновление системы (23 пакета), обновление KDE (15 пакетов), обновление Firefox, LibreOffice и т.д., что делает процесс более понятным для пользователя.
Он видит пакеты обновления системы и пакеты обновления приложений, что гораздо удобнее чем длинный список непонятных пакетов.
При перезагрузке, если systemd видит скачанные обновления, то он загружает систему в специальный безопасный режим и начинает установку обновлений.
Если при этом произошло отключение питания, то при следующей загрузке systemd повторит эту процедуру. А если при установке обновлений произошли ошибки, то systemd откатит состояние системы.
При загрузке в нормальном режиме пользователь получит сообщение либо об успешном обновлении системы, либо об ошибке.
При этом возможно частичное обновление системы, если сбойный пакет не препятствует установке других обновлений.
Таким образом процесс обновления становится проще для пользователя и вписывается в его привычный пользовательский опыт, когда установка обновлений происходит при перезагрузке.
С технической стороны это делает систему более надежной и практически на 100% гарантирует ее загрузку в графическом режиме (за исключением действительно серьезных проблем).
👍31❤6🤮1👌1
Специальные символы-операторы командной строки Linux
В командной строке Linux широко используются символы-операторы, значительно расширяющие ее возможности, но они же становятся серьезным затруднением для начинающих, так как при внешней схожести несут абсолютно разный смысл.
Начнем с символа
К удивлению запустившего, первая команда запустится в фоне, а вторая одновременно с ней, но интерактивно. Понятно, что требуемая задача выполнена не будет.
Для объединения команд используется оператор
Вторая команда выполниться только при успешном выполнении первой, т.е. если она вернула код выхода 0.
Поэтому правильная команда для обновления системы будет выглядеть так:
А вот если мы поставим подряд две трубы -
В более сложных конструкциях можно использовать
В командной строке Linux широко используются символы-операторы, значительно расширяющие ее возможности, но они же становятся серьезным затруднением для начинающих, так как при внешней схожести несут абсолютно разный смысл.
Начнем с символа
& - амперсанд. Этот оператор заставляет команду работать в фоновом режиме. Т.е. если вы знаете, что команда выполняется какое-то продолжительное время, просто отправьте ее в фон следующим образом:command &
Но будет ошибкой использовать ее для объединения команд, чаще всего ошибаются похожим образом:apt update -y & apt full-upgrade -y К удивлению запустившего, первая команда запустится в фоне, а вторая одновременно с ней, но интерактивно. Понятно, что требуемая задача выполнена не будет.
Для объединения команд используется оператор
&& - логическое И. Несмотря на всю схожесть с прошлым оператором ее смысл совсем иной. В конструкции: command _1 && command _2 Вторая команда выполниться только при успешном выполнении первой, т.е. если она вернула код выхода 0.
Поэтому правильная команда для обновления системы будет выглядеть так:
apt update -y && apt full-upgrade -y && apt autoremove -y
Также все знают оператор | - пайп или труба. Он позволяет передать поток вывода одной команды в поток входа другой.А вот если мы поставим подряд две трубы -
|| - то получим оператор логическое ИЛИ, в конструкции:command _1 || command _2
Вторая команда будет выполнена только тогда, если первая вернет код ошибки. В более сложных конструкциях можно использовать
И – ИЛИ: command _1 && command _2 || command _3
Если первая команда завершилась успешно, то будет выполнена команда 2, иначе – команда 3.
👍51❤5
PortQry v 2.0 – консольный сканер портов для Windows
Инструментов для диагностики сети хватает, но лишних среди них не бывает, поэтому сегодня хотим рассказать о консольном сетевом сканере от Microsoft - PortQry v 2.0, получить его можно на официальной странице: https://www.microsoft.com/en-us/download/details.aspx?id=17148
Использовать ее довольно просто, нам потребуется указать несколько параметров:
-n – точка назначения – имя или адрес сетевого узла
-p – протокол, доступны значения: tcp, udp, both, по умолчанию tcp.
-e – порт назначения
-o – перечень портов через запятую
-r - диапазон портов через двоеточие
Например:
или
В зависимости от результата вы получите одно из значений:
Listening – если порт открыт и ответ от него получен
Not Listening – если на целевом узле не запущен процесс обслуживающий порт и система сообщает ICMP «Destination Unreachable - Port Unreachable» или получен TCP-пакет с флагом Reset.
Filtered – если система не направила никакого ответа или запрос был отфильтрован брандмауэром.
Но это далеко не все, иначе данный инструмент просто ничем не выбивался из категории себе подобных.
Основная проблема заключается в том, что многие сетевые службы могут не отвечать на неформатированный запрос, а отвечают только на сообщения, использующие определенный уровень сеанса или прикладной протокол.
Таким образом, чтобы определить, действительно ли порт открыт или фильтруется PortQry использует расширенные проверки для ряда протоколов, в их число входят: LDAP, RPC, SMTP/POP3/IMAP4, SNMP, FTP/TFTP, NetBIOS, MS SQL, L2TP и ряд других.
На картинке внизу показан запрос к порту MS SQL, утилита первоначально проверила порт и выдала предварительную оценку: LISTENING or FILTERED.
После чего выполнила расширенную проверку и убедилась, что на данном узле запущен экземпляр службы SQLEXPRESS и окончательный вердикт стал LISTENING.
В некоторых случаях может потребоваться использовать определенный порт источника, в этом случае используйте следующий ключ (указанный порт не должен использоваться другими процессами):
Кроме того, у утилиты существует локальный режим, в котором она работает с сетевыми процессами хоста, в этом варианте интересными могут быть ключи:
-local – показывает информацию обо всех активных портах и соединениях локального узла
-wport – мониторит сетевую активность указанного порта
- wpid – мониторит сетевую активность процесса с указанным PID
Данные возможность удобно использовать с записью в лог файл:
Где ключ -wt задает частоту опроса в секундах, доступные значение 1-1200, по умолчанию 60 сек, а ключ -l указывает файл журнала, при указании относительного пути журнал создается в директории с утилитой.
Размер заметки не позволяет перечислить все возможности, поэтому дадим ссылку на страничку официальной документации: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2
А также советуем взять утилиту на вооружение, особенно если вам приходится часто заниматься устранением неисправностей и диагностикой Windows сетей.
Инструментов для диагностики сети хватает, но лишних среди них не бывает, поэтому сегодня хотим рассказать о консольном сетевом сканере от Microsoft - PortQry v 2.0, получить его можно на официальной странице: https://www.microsoft.com/en-us/download/details.aspx?id=17148
Использовать ее довольно просто, нам потребуется указать несколько параметров:
-n – точка назначения – имя или адрес сетевого узла
-p – протокол, доступны значения: tcp, udp, both, по умолчанию tcp.
-e – порт назначения
-o – перечень портов через запятую
-r - диапазон портов через двоеточие
Например:
PortQry.exe -n 192.168.100.125 -p udp -e 1194
или
PortQry.exe -n 192.168.100.125 -o 80, 443
В зависимости от результата вы получите одно из значений:
Listening – если порт открыт и ответ от него получен
Not Listening – если на целевом узле не запущен процесс обслуживающий порт и система сообщает ICMP «Destination Unreachable - Port Unreachable» или получен TCP-пакет с флагом Reset.
Filtered – если система не направила никакого ответа или запрос был отфильтрован брандмауэром.
Но это далеко не все, иначе данный инструмент просто ничем не выбивался из категории себе подобных.
Основная проблема заключается в том, что многие сетевые службы могут не отвечать на неформатированный запрос, а отвечают только на сообщения, использующие определенный уровень сеанса или прикладной протокол.
Таким образом, чтобы определить, действительно ли порт открыт или фильтруется PortQry использует расширенные проверки для ряда протоколов, в их число входят: LDAP, RPC, SMTP/POP3/IMAP4, SNMP, FTP/TFTP, NetBIOS, MS SQL, L2TP и ряд других.
На картинке внизу показан запрос к порту MS SQL, утилита первоначально проверила порт и выдала предварительную оценку: LISTENING or FILTERED.
После чего выполнила расширенную проверку и убедилась, что на данном узле запущен экземпляр службы SQLEXPRESS и окончательный вердикт стал LISTENING.
В некоторых случаях может потребоваться использовать определенный порт источника, в этом случае используйте следующий ключ (указанный порт не должен использоваться другими процессами):
PortQry.exe -n 192.168.100.125 -sp 25 -e 25
Кроме того, у утилиты существует локальный режим, в котором она работает с сетевыми процессами хоста, в этом варианте интересными могут быть ключи:
-local – показывает информацию обо всех активных портах и соединениях локального узла
-wport – мониторит сетевую активность указанного порта
- wpid – мониторит сетевую активность процесса с указанным PID
Данные возможность удобно использовать с записью в лог файл:
PortQry.exe -wport 3389 -wt 5 -l rdplog.txt
Где ключ -wt задает частоту опроса в секундах, доступные значение 1-1200, по умолчанию 60 сек, а ключ -l указывает файл журнала, при указании относительного пути журнал создается в директории с утилитой.
Размер заметки не позволяет перечислить все возможности, поэтому дадим ссылку на страничку официальной документации: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2
А также советуем взять утилиту на вооружение, особенно если вам приходится часто заниматься устранением неисправностей и диагностикой Windows сетей.
👍36🔥5❤3⚡1
Forwarded from The IT Director | Авторский канал про IT & eCom
Denwer. Кто помнит — уже не джун
Напомнили сегодня про Denwer — тот самый джентльменский набор разработчика. Кто ставил — поймёт. Кто не ставил… ну вы просто молоды)) забавно было вспоминать про инструменты, которые выдают в тебе возвраст разработчика, и объяснять это тем, кто в IT недавно)
🔥 Кто помнит — ставим огоньки)
© TheITDirector - авторский канал ИТ директора про опыт и системность.
#webdev #php #алдытут
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFK1Bi2t
Напомнили сегодня про Denwer — тот самый джентльменский набор разработчика. Кто ставил — поймёт. Кто не ставил… ну вы просто молоды)) забавно было вспоминать про инструменты, которые выдают в тебе возвраст разработчика, и объяснять это тем, кто в IT недавно)
🔥 Кто помнит — ставим огоньки)
© TheITDirector - авторский канал ИТ директора про опыт и системность.
#webdev #php #алдытут
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFK1Bi2t
🔥149❤4👍3🤮2🤡2
Как узнать какие пакеты установлены из определенного репозитория
Очень часто, наводя порядок или планируя обновление системы встает вопрос о подключенных репозиториях, в частности о том, для чего они нужны и какие пакеты из них установлены.
Прямого способа сделать это нет, но Linux тем и хорош, что позволяет решить задачу различными способами, в нашем случае мы будем использовать
Чтобы получить интересующую нас информацию прежде всего выведем список подключенных репозиториев командой:
В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа
Теперь мы можем получить полный список пакетов из этого репозитория командой:
В данном случае указываем наименование источника сразу после ключа
Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени.
В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:
Здесь мы соединили через логическое И два условия: пакет установлен
Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория
Но здесь нас может поджидать несколько иная сложность, среди установленных пактов нам могут попасться пакеты со статусом [установлен, автоматически] и их может быть много, очень много.
Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:
Где параметр
Данные конструкции можно использовать не только с командой
Ну или обратившись к подобной информации в сети интернет.
Очень часто, наводя порядок или планируя обновление системы встает вопрос о подключенных репозиториях, в частности о том, для чего они нужны и какие пакеты из них установлены.
Прямого способа сделать это нет, но Linux тем и хорош, что позволяет решить задачу различными способами, в нашем случае мы будем использовать
apt-patterns, позволяющий использовать регулярные выражения с командами apt.Чтобы получить интересующую нас информацию прежде всего выведем список подключенных репозиториев командой:
apt policy
В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа
o=. Теперь мы можем получить полный список пакетов из этого репозитория командой:
apt list ~Onginx
В данном случае указываем наименование источника сразу после ключа
~O, без пробела. Обратите внимание, что данная команда выводит все пакеты, содержащиеся в репозитории, установленные пакеты при этом помечены отдельно как [установлен].Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени.
В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:
apt list ?and\(~i\,~Oprox\)
Здесь мы соединили через логическое И два условия: пакет установлен
~i и пакет принадлежит определенному источнику ~O, также не забывайте использовать обратный слеш для экранирования служебных символов.Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория
o=Proxmox мы использовали просто ~Oprox.Но здесь нас может поджидать несколько иная сложность, среди установленных пактов нам могут попасться пакеты со статусом [установлен, автоматически] и их может быть много, очень много.
Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:
apt list ?and\(~i\,\!~M\,~Oprox\)
Где параметр
!~M обозначает «кроме установленных автоматически». Теперь вывод команды покажет только пакеты, которые были установлены вручную из указанного репозитория. Данные конструкции можно использовать не только с командой
apt list, но и с любыми другими командами apt, например для установки или удаления пакетов. А больше информации вы можете получить при помощи: man apt-patterns
Ну или обратившись к подобной информации в сети интернет.
1👍21❤4⚡1
Узкий профиль или болото?
В комментариях недавно всплыл вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).
На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.
Несомненно, что так оно и есть, особенно среди специфических промышленных систем. Но есть один тонкий момент – квалификация, точнее ее потеря. А чтобы было понятнее что под этим имеется ввиду я специально попросил написать эту заметку коллегу, который побывал в подобной ситуации.
Далее от его лица, моя только литературная обработка.
Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.
Но зато он отлично тянул еще одно внутреннее приложение, которое отвечало за всю внутреннюю кухню, включая производство и даже расчет зарплаты. Понемногу втянулся в это дело и я. Приложение было полностью самописное, на базе FoxPro.
Шли годы, мой начальник ушел на пенсию, и я занял его место, по деньгам было неплохо, я стал обрастать жирком и в какое-то время перестал интересоваться делами в отрасли. Ну не до того. На работе своих дел хватает, а дома семья, дети, стройка.
Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.
Жизнь шла по налаженной стезе, и я даже немного гордился тем, что я достаточно редкий специалист, так как найти кого-то на этот стек было практически невозможно.
Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.
И вот тут я понял, что жизнь прошла мимо меня и я все пропустил. Ребята говорили о каких-то абсолютно неведомых мне вещах: Linux, виртуализация, контейнеры, кластеры, веб-сервисы. При том, что «серверная» там составляла всего один небольшой шкафчик.
Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.
А дальше я понял, что как специалист я представляю из себя практически полный ноль и никому кроме своего «дяди» я не нужен.
Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.
В общем весь этот проект я активно вникал в используемые в нем технологии, много спрашивал про то, как, что и на чем. И все больше понимал, насколько я отстал и что с этим нужно срочно что-то делать.
Но что делать как-то в голову не приходило. Да, надо было учить, но когда?
Второй звоночек прозвенел, когда я уехал на месяц по семейным обстоятельствам и работать мог урывками и то удаленно. После чего и мне и дяде стало понятно, что никто кроме меня всю нашу кухню не тянет.
По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.
После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.
Сейчас я второй год активно переделываю всю внутреннюю кухню, от старого приложения отказаться еще не получилось, но многое уже перевели на современные технологии.
В комментариях недавно всплыл вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).
На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.
Несомненно, что так оно и есть, особенно среди специфических промышленных систем. Но есть один тонкий момент – квалификация, точнее ее потеря. А чтобы было понятнее что под этим имеется ввиду я специально попросил написать эту заметку коллегу, который побывал в подобной ситуации.
Далее от его лица, моя только литературная обработка.
Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.
Но зато он отлично тянул еще одно внутреннее приложение, которое отвечало за всю внутреннюю кухню, включая производство и даже расчет зарплаты. Понемногу втянулся в это дело и я. Приложение было полностью самописное, на базе FoxPro.
Шли годы, мой начальник ушел на пенсию, и я занял его место, по деньгам было неплохо, я стал обрастать жирком и в какое-то время перестал интересоваться делами в отрасли. Ну не до того. На работе своих дел хватает, а дома семья, дети, стройка.
Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.
Жизнь шла по налаженной стезе, и я даже немного гордился тем, что я достаточно редкий специалист, так как найти кого-то на этот стек было практически невозможно.
Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.
И вот тут я понял, что жизнь прошла мимо меня и я все пропустил. Ребята говорили о каких-то абсолютно неведомых мне вещах: Linux, виртуализация, контейнеры, кластеры, веб-сервисы. При том, что «серверная» там составляла всего один небольшой шкафчик.
Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.
А дальше я понял, что как специалист я представляю из себя практически полный ноль и никому кроме своего «дяди» я не нужен.
Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.
В общем весь этот проект я активно вникал в используемые в нем технологии, много спрашивал про то, как, что и на чем. И все больше понимал, насколько я отстал и что с этим нужно срочно что-то делать.
Но что делать как-то в голову не приходило. Да, надо было учить, но когда?
Второй звоночек прозвенел, когда я уехал на месяц по семейным обстоятельствам и работать мог урывками и то удаленно. После чего и мне и дяде стало понятно, что никто кроме меня всю нашу кухню не тянет.
По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.
После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.
Сейчас я второй год активно переделываю всю внутреннюю кухню, от старого приложения отказаться еще не получилось, но многое уже перевели на современные технологии.
👍59❤9⚡4🤡3💯1
Forwarded from The IT Director | Авторский канал про IT & eCom
Ошибки в eCommerce, которые не видны, но вы за них заплатите
Сайт был удобный, продажи шли, товар учитывался через 1С.
Но была одна тонкость:
когда клиент клал товар в корзину и оформлял заказ, товар уходил в резерв.
Если заказ не оплачивали — он так и оставался в резерве.
А в системе — числился как “уже выкуплен”.
На практике это выглядело так:
— товар лежит на складе
— система считает, что его нет
— клиенту он не показывается
— никто не понимает, почему он не продаётся
Сотрудники должны были вручную снимать такие заказы с резерва. Но, как и бывает, просто забывали.
В результате: остатки искажены, товар не участвует в продаже, реклама идёт в холостую, и бизнес теряет деньги.
Решили это просто:
— автоматическое снятие заказа из резерва, если не был оплачен в течение N часов
— уведомления в админку
— чистка “мертвых” резервов
— восстановление остатка без участия человека
Такие кейсы вытаскиваются в результате аудита: когда смотришь на связку сайт ↔ 1С ↔ склад, а не просто на “работает / не работает”.
Это то, с чего часто начинается реальная оптимизация в eCommerce. Не с редизайна и не с новой CMS. А с устранения глухих узлов, которые просто не видно в интерфейсе.
-------
Было интересно? Если вы — владелец бизнеса, руководитель, развиваете свой продукт или просто хотите работать системно и результативно — здесь будет полезно, нажимайте на ссылку ниже и подписывайтесь
© TheITDirector - авторский канал
#ecommerce #разбор
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFHSkTqr
Сайт был удобный, продажи шли, товар учитывался через 1С.
Но была одна тонкость:
когда клиент клал товар в корзину и оформлял заказ, товар уходил в резерв.
Если заказ не оплачивали — он так и оставался в резерве.
А в системе — числился как “уже выкуплен”.
На практике это выглядело так:
— товар лежит на складе
— система считает, что его нет
— клиенту он не показывается
— никто не понимает, почему он не продаётся
Сотрудники должны были вручную снимать такие заказы с резерва. Но, как и бывает, просто забывали.
В результате: остатки искажены, товар не участвует в продаже, реклама идёт в холостую, и бизнес теряет деньги.
Решили это просто:
— автоматическое снятие заказа из резерва, если не был оплачен в течение N часов
— уведомления в админку
— чистка “мертвых” резервов
— восстановление остатка без участия человека
Такие кейсы вытаскиваются в результате аудита: когда смотришь на связку сайт ↔ 1С ↔ склад, а не просто на “работает / не работает”.
Это то, с чего часто начинается реальная оптимизация в eCommerce. Не с редизайна и не с новой CMS. А с устранения глухих узлов, которые просто не видно в интерфейсе.
-------
Было интересно? Если вы — владелец бизнеса, руководитель, развиваете свой продукт или просто хотите работать системно и результативно — здесь будет полезно, нажимайте на ссылку ниже и подписывайтесь
© TheITDirector - авторский канал
#ecommerce #разбор
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFHSkTqr
👍8🤮4❤2🔥2🤣1
😎 БезопасноеХранилищеДанных в 1С такое безопасное...
Все знают про то, что не стоит верить написанному на заборе. Как оказалось написанному в 1С тоже.
Сегодня потребовалось узнать пароль от FTP сохраненный в 1С. Как оказалось - нет ничего проще, он открытым текстом лежит в регистре Безопасное Хранилище Данных.
Готовая обработка здесь: https://infostart.ru/public/1155324/
Хотя она за 5 минут пишется на коленке.
Это мы к чему? Да к тому, что любой, кто имеет доступ к базе и владеет программированием под 1С быстро и непринужденно вытащит ВСЕ сохраненные в базе пароли.
Все знают про то, что не стоит верить написанному на заборе. Как оказалось написанному в 1С тоже.
Сегодня потребовалось узнать пароль от FTP сохраненный в 1С. Как оказалось - нет ничего проще, он открытым текстом лежит в регистре Безопасное Хранилище Данных.
Готовая обработка здесь: https://infostart.ru/public/1155324/
Хотя она за 5 минут пишется на коленке.
Это мы к чему? Да к тому, что любой, кто имеет доступ к базе и владеет программированием под 1С быстро и непринужденно вытащит ВСЕ сохраненные в базе пароли.
😁14👀7👍4
Узкий профиль или болото? Часть 2.
Продолжаем рассказ, написанный по моей просьбе коллегой, повествование идет от его лица.
В общем, поговорив с дядей я занялся внедрением современных технологий, прежде всего на те участки, где у нас были узкие места. А они были, прежде всего в оперативном обмене информацией между подразделениями.
И именно это больше всего тревожило собственника. Интернет-торговля уже начинала наступать на пятки и нас выручало в основном то, что отделочные и строительные материалы люди предпочитают посмотреть и потрогать перед покупкой.
У нас же выставочный зал представлял в основном образцы, плюс тут же был небольшой склад с мелочевкой. Остальное или на первом складе, километрах в трех от нас, или на производственной площадке, на другом конце города.
Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.
Все это приводило к тому, что данные из центрального офиса могли попасть на склады с задержкой до получаса. И это начало создавать серьезные сложности, особенно с постоянными клиентами из числа строительных бригад, у которых были лимиты на отгрузку без оплаты, которые могли динамически меняться в зависимости от объемов и платежной дисциплины.
А теперь представьте, клиент неправильно посчитал плитку, бригада на объекте, нужно срочно еще ящик-другой. Бригадир берет кусок плитки и едет сразу на склад. Находят нужную партию и дальше начинаются качели длинной в полчаса.
Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.
А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.
И этот вопрос никак на текущем стеке технологий не решался. Поэтому первым делом стали внедрять веб-сервисы. Просто не было, пришлось практически все изучать с нуля, для меня и моих коллег это буквально была новая планета.
Но справились и когда мы это внедрили даже в зачаточном состоянии, то получили эффект разорвавшейся бомбы. Все сразу начали спрашивать: а что, так можно было, и почему вы раньше так не сделали?
Теперь при наличии связи любой заказ, лимит или баланс виден в режиме реального времени. Это очень сильно подняло и нашу самооценку, и наш рейтинг в глазах руководства. Потому что мы решили одну из главных проблем и сразу же получили зеленый свет на дальнейшие действия.
А после мы занялись внутренней инфраструктурой, потому что там было что-то просто ужасающее.
К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.
В итоге на физических серверах в итоге собрались такие причудливые сочетания служб, что сам уже не понимал как оно там все устроено и работает. В полный рост применялся принцип: работает – не трогай.
Я не говорю уже про профилактику или апдейты, все это приходилось делать в глубоко нерабочее время и постоянно думать об одном: лишь бы взлетело.
В итоге младший персонал просто боялся что-то там трогать, и я невольно стал «незаменимым», что не нравилось ни мне, ни руководству.
Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.
Кроме того, появилась возможность разделить роли между сотрудниками. Этот отвечает за почту, этот за сайт, а этот за базы данных. У каждого свои виртуалки, свой объем работ и свой уровень ответственности.
И да, теперь я специалист самого широкого профиля и не являюсь незаменимым. Зато я могу спокойно уехать на две недели к морю и пить пиво на пляже, не вздрагивая от каждого звука из телефона.
Продолжаем рассказ, написанный по моей просьбе коллегой, повествование идет от его лица.
В общем, поговорив с дядей я занялся внедрением современных технологий, прежде всего на те участки, где у нас были узкие места. А они были, прежде всего в оперативном обмене информацией между подразделениями.
И именно это больше всего тревожило собственника. Интернет-торговля уже начинала наступать на пятки и нас выручало в основном то, что отделочные и строительные материалы люди предпочитают посмотреть и потрогать перед покупкой.
У нас же выставочный зал представлял в основном образцы, плюс тут же был небольшой склад с мелочевкой. Остальное или на первом складе, километрах в трех от нас, или на производственной площадке, на другом конце города.
Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.
Все это приводило к тому, что данные из центрального офиса могли попасть на склады с задержкой до получаса. И это начало создавать серьезные сложности, особенно с постоянными клиентами из числа строительных бригад, у которых были лимиты на отгрузку без оплаты, которые могли динамически меняться в зависимости от объемов и платежной дисциплины.
А теперь представьте, клиент неправильно посчитал плитку, бригада на объекте, нужно срочно еще ящик-другой. Бригадир берет кусок плитки и едет сразу на склад. Находят нужную партию и дальше начинаются качели длинной в полчаса.
Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.
А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.
И этот вопрос никак на текущем стеке технологий не решался. Поэтому первым делом стали внедрять веб-сервисы. Просто не было, пришлось практически все изучать с нуля, для меня и моих коллег это буквально была новая планета.
Но справились и когда мы это внедрили даже в зачаточном состоянии, то получили эффект разорвавшейся бомбы. Все сразу начали спрашивать: а что, так можно было, и почему вы раньше так не сделали?
Теперь при наличии связи любой заказ, лимит или баланс виден в режиме реального времени. Это очень сильно подняло и нашу самооценку, и наш рейтинг в глазах руководства. Потому что мы решили одну из главных проблем и сразу же получили зеленый свет на дальнейшие действия.
А после мы занялись внутренней инфраструктурой, потому что там было что-то просто ужасающее.
К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.
В итоге на физических серверах в итоге собрались такие причудливые сочетания служб, что сам уже не понимал как оно там все устроено и работает. В полный рост применялся принцип: работает – не трогай.
Я не говорю уже про профилактику или апдейты, все это приходилось делать в глубоко нерабочее время и постоянно думать об одном: лишь бы взлетело.
В итоге младший персонал просто боялся что-то там трогать, и я невольно стал «незаменимым», что не нравилось ни мне, ни руководству.
Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.
Кроме того, появилась возможность разделить роли между сотрудниками. Этот отвечает за почту, этот за сайт, а этот за базы данных. У каждого свои виртуалки, свой объем работ и свой уровень ответственности.
И да, теперь я специалист самого широкого профиля и не являюсь незаменимым. Зато я могу спокойно уехать на две недели к морю и пить пиво на пляже, не вздрагивая от каждого звука из телефона.
👍61❤11🤡3⚡2🤮2
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Никакого заумного синтаксиса, никаких ключей. Все просто, понятно, наглядно. И не надо никаких онлайн сервисов, достаточно просто запустить терминал.
👍52🔥9❤8⚡1
Узкий профиль или болото? Заключение.
На этих выходных мы обсуждали ситуацию, когда используемый стек технологий негативно отражается на развитии специалиста и приводит к фактическому застою.
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
На этих выходных мы обсуждали ситуацию, когда используемый стек технологий негативно отражается на развитии специалиста и приводит к фактическому застою.
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
👍51❤7🤡3🤮2
Не было печали – апдейтов накачали. Июньский вторник патчей
В рамках июньского вторника патчей Microsoft выпустила накопительное обновление безопасности, в котором закрыли две серьезных и эксплуатируемых уязвимости нулевого дня:
🔹 CVE-2025-33053— уязвимость удаленного выполнения кода в WEBDAV
🔹 CVE-2025-33073 — уязвимость повышения привилегий в SMB-клиенте Windows
Одновременно с этим выяснилось, что попутно сломали службу DHCP-сервера, которая перестает отвечать на запросы продления аренды клиентами. В настоящий момент исправления данной проблемы нет, Microsoft обещает выпустить исправления «как только – так сразу».
Проблемой затронуты следующие системы:
▫️ Windows Server 2025 – обновление KB5060842
▫️Windows Server 2022 - обновление KB5060526
▫️Windows Server 2019 - обновление KB5060531
▫️Windows Server 2016 - обновление KB5061010
Если эта проблема коснулась вас, то следует трезво взвесить все плюсы и минусы, так как простое удаление обновления делает систему уязвимой.
В рамках июньского вторника патчей Microsoft выпустила накопительное обновление безопасности, в котором закрыли две серьезных и эксплуатируемых уязвимости нулевого дня:
🔹 CVE-2025-33053— уязвимость удаленного выполнения кода в WEBDAV
🔹 CVE-2025-33073 — уязвимость повышения привилегий в SMB-клиенте Windows
Одновременно с этим выяснилось, что попутно сломали службу DHCP-сервера, которая перестает отвечать на запросы продления аренды клиентами. В настоящий момент исправления данной проблемы нет, Microsoft обещает выпустить исправления «как только – так сразу».
Проблемой затронуты следующие системы:
▫️ Windows Server 2025 – обновление KB5060842
▫️Windows Server 2022 - обновление KB5060526
▫️Windows Server 2019 - обновление KB5060531
▫️Windows Server 2016 - обновление KB5061010
Если эта проблема коснулась вас, то следует трезво взвесить все плюсы и минусы, так как простое удаление обновления делает систему уязвимой.
👀13😱9🤷♂5👍4🤡4
Сканируем сеть при помощи PowerShell
Часто стоит задача узнать на каком узле сети запущен тот или иной сервис и доступен ли он. Можно, конечно, скачать какое-либо подходящее ПО, а можно воспользоваться PowerShell.
Думаю, все знают командлет
Часто стоит задача узнать на каком узле сети запущен тот или иной сервис и доступен ли он. Можно, конечно, скачать какое-либо подходящее ПО, а можно воспользоваться PowerShell.
Думаю, все знают командлет
Test-NetConnection, который позволяет проверить открытый TCP порт, например:Test-NetConnection srv-01 -Port 443
В результате получим сообщение о том, доступен ли порт и еще ряд полезной информации об узле. Если же нам нужен просто ответ да или нет, то сократим разговорчивость команды: Test-NetConnection srv-01 -Port 443 -InformationLevel "Quiet"
А теперь превратим этот командлет в простейший сканер как говорится, не вставая со стула, пишем простой однострочный скрипт:foreach ($ip in 1..254) {Test-NetConnection -Port 443 -InformationLevel "Detailed" 192.168.0.$ip}
Который просканирует адреса с 1 по 254 и выдаст подробный вывод по каждому узлу. Работает не быстро, но свою работу делает. Если нужно просто знать открыт порт или закрыт, то меняем -InformationLevel "Detailed"
на -InformationLevel "Quiet"
И чем хорош данный вариант, что это PowerShell и мы можем продолжать обрабатывать результат дальше или вообще оформить все отдельным скриптом.
👍55