Получил сегодня довольно интересную железку, немного протестировал, рассказываю.
Что это такое? Это своего рода док для дисков M.2, который позволяет быстро и просто подключить такой диск к ПК. Собственно, ради этого и покупалось, чтобы лишний раз не раскручивать и не прикручивать в стандартных внешних боксах, когда надо быстро подключить чужой диск.
Да и количество подключений у стандартного разъема ограничено, здесь же все сделано достаточно надежно. Сам корпус на резиновых ножках, по столу не ездит, диски фиксируются хорошо, не болтаются.
В системе определяется как HIKSEMI MD202, если поискать, то модель достаточно распространенная, продается много где в разном виде.
Официальная спецификация о скоростях молчит, указывая только скорость интерфейса – 10 Гбит/с, т.е. стандартную для USB 3.2 Gen 2. Ну мы не гордые, потестим сами.
В док можно ставить диски M key и B + M key форматов SATA и NVMe, что перекрывает все текущие потребности.
Итак, NVME - скорость записи и чтения не превышают 450 МБ/с, не фонтан, но в целом нормально. SATA – чтение те же 450 МБ/с, а вот запись стабильно просаживается до 130 МБ/с, скорее всего из-за дополнительного преобразования интерфейса.
Общий вывод – за свою цену в 800 руб. на ОЗОНе брать можно, но иллюзий не испытывать. Нужны скорости – берите нормальный бокс, нужно по быстрому посмотреть что там на диске, что-то слить или залить в небольших объемах – то, что доктор прописал.
Что это такое? Это своего рода док для дисков M.2, который позволяет быстро и просто подключить такой диск к ПК. Собственно, ради этого и покупалось, чтобы лишний раз не раскручивать и не прикручивать в стандартных внешних боксах, когда надо быстро подключить чужой диск.
Да и количество подключений у стандартного разъема ограничено, здесь же все сделано достаточно надежно. Сам корпус на резиновых ножках, по столу не ездит, диски фиксируются хорошо, не болтаются.
В системе определяется как HIKSEMI MD202, если поискать, то модель достаточно распространенная, продается много где в разном виде.
Официальная спецификация о скоростях молчит, указывая только скорость интерфейса – 10 Гбит/с, т.е. стандартную для USB 3.2 Gen 2. Ну мы не гордые, потестим сами.
В док можно ставить диски M key и B + M key форматов SATA и NVMe, что перекрывает все текущие потребности.
Итак, NVME - скорость записи и чтения не превышают 450 МБ/с, не фонтан, но в целом нормально. SATA – чтение те же 450 МБ/с, а вот запись стабильно просаживается до 130 МБ/с, скорее всего из-за дополнительного преобразования интерфейса.
Общий вывод – за свою цену в 800 руб. на ОЗОНе брать можно, но иллюзий не испытывать. Нужны скорости – берите нормальный бокс, нужно по быстрому посмотреть что там на диске, что-то слить или залить в небольших объемах – то, что доктор прописал.
Альт 11 – в лесу что-то сдохло…
Да, именно так, в лесу наконец что-то сдохло. Потому что новый выпуск Альт Рабочая станция 11 неожиданно вышел с графической оболочкой GNOME и ее даже не смогли испохабить, что они ранее успешно делали с тем же XFCE или Cinnamon.
Поставили, посмотрели. Live-режима у загрузочного диска нет, поэтому взлетит или не взлетит на вашем железе узнаете уже по факту. Но скорее всего взлетит, под капотом свежее LTS ядро 6.12.
Инсталлятор классический, альтовский. Скучать не даст, потому что все время надо что-то нажимать и отвечать (прямо как в Debian). Современный подход: ответили на вопросы – нажали кнопку и пошли сюда еще не завезли.
Внутри все выглядит свежо и интересно. С одной стороны это классический Альт, а с другой он графически хорош собой. Можете использовать как классический GNOME (он тут с пылу, с жару – 47 версия) или «панельный режим», который настраивает GNOME в стиле классических интерфейсов и приближает внешне к интерфейсу Рабочей станции 10.
Какой-то кастомизации именно под Альт тут нет и это, наверное, хорошо. Есть неплохие обои с родными просторами. А дальше каждый сам волен самовыражаться как пожелает, под GNOME всякого добра хватает.
Данная версия предназначена для тестирования, в продажу пойдет Альт 11.1, что тоже верно, хотя Альт в этот раз серьезно отстал от своих основных конкурентов – РЕД ОС и Астры, которые выпустили новые версии еще весной-летом прошлого года.
Подробный обзор будет после праздников, когда вернусь из мини-отпуска. Впечатление от Альт 11, в отличии от РОСА 13, хорошее, видна работа и прогресс. Можно качать тестировать, для физлиц использование бесплатно.
Да, именно так, в лесу наконец что-то сдохло. Потому что новый выпуск Альт Рабочая станция 11 неожиданно вышел с графической оболочкой GNOME и ее даже не смогли испохабить, что они ранее успешно делали с тем же XFCE или Cinnamon.
Поставили, посмотрели. Live-режима у загрузочного диска нет, поэтому взлетит или не взлетит на вашем железе узнаете уже по факту. Но скорее всего взлетит, под капотом свежее LTS ядро 6.12.
Инсталлятор классический, альтовский. Скучать не даст, потому что все время надо что-то нажимать и отвечать (прямо как в Debian). Современный подход: ответили на вопросы – нажали кнопку и пошли сюда еще не завезли.
Внутри все выглядит свежо и интересно. С одной стороны это классический Альт, а с другой он графически хорош собой. Можете использовать как классический GNOME (он тут с пылу, с жару – 47 версия) или «панельный режим», который настраивает GNOME в стиле классических интерфейсов и приближает внешне к интерфейсу Рабочей станции 10.
Какой-то кастомизации именно под Альт тут нет и это, наверное, хорошо. Есть неплохие обои с родными просторами. А дальше каждый сам волен самовыражаться как пожелает, под GNOME всякого добра хватает.
Данная версия предназначена для тестирования, в продажу пойдет Альт 11.1, что тоже верно, хотя Альт в этот раз серьезно отстал от своих основных конкурентов – РЕД ОС и Астры, которые выпустили новые версии еще весной-летом прошлого года.
Подробный обзор будет после праздников, когда вернусь из мини-отпуска. Впечатление от Альт 11, в отличии от РОСА 13, хорошее, видна работа и прогресс. Можно качать тестировать, для физлиц использование бесплатно.
Forwarded from Записки IT специалиста
Что будет если мы выполним chmod -R 777 / с правами суперпользователя?
Ну казалось бы, чего такого, ну дадим всем полные права, что может пойти не так? Ну про безопасность понятно…
Но с этого момента пойдет не так решительно все. Очень многие службы и системные утилиты требуют определенных прав доступа на файлы, к таким файлам могут относится ключи, сертификаты, конфигурационные файлы, отвечающие за безопасность и т.д. и т.п.
Поэтому такие службы будут работать до рестарта и более не запустятся, сразу откажут такие утилиты как sudo, также вы не сможете войти с использованием ключа по SSH.
А еще вспоминаем, что 777 – это на самом деле 0777, т.е. легким движением руки мы снесем все SUID, SGID и Sticky bit. После чего откажет большая часть системных утилит и наступит неуправляемый хаос в /tmp.
Сама же система будет работать и даже загружаться, но по факту мы ее сделали полностью неработоспособной. Самое лучшее что мы можем сделать – это скопировать данные и переустановить ее.
Ну казалось бы, чего такого, ну дадим всем полные права, что может пойти не так? Ну про безопасность понятно…
Но с этого момента пойдет не так решительно все. Очень многие службы и системные утилиты требуют определенных прав доступа на файлы, к таким файлам могут относится ключи, сертификаты, конфигурационные файлы, отвечающие за безопасность и т.д. и т.п.
Поэтому такие службы будут работать до рестарта и более не запустятся, сразу откажут такие утилиты как sudo, также вы не сможете войти с использованием ключа по SSH.
А еще вспоминаем, что 777 – это на самом деле 0777, т.е. легким движением руки мы снесем все SUID, SGID и Sticky bit. После чего откажет большая часть системных утилит и наступит неуправляемый хаос в /tmp.
Сама же система будет работать и даже загружаться, но по факту мы ее сделали полностью неработоспособной. Самое лучшее что мы можем сделать – это скопировать данные и переустановить ее.
Копируй, вставляй и молись
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Не стесняйтесь адаптировать код существующих скриптов для своих нужд. Но не занимайтесь программированием по принципу «копируй, вставляй и молись», когда вы не понимаете код. Найдите время, чтобы разобраться в этом. Это время никогда не тратится зря.
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Не стесняйтесь адаптировать код существующих скриптов для своих нужд. Но не занимайтесь программированием по принципу «копируй, вставляй и молись», когда вы не понимаете код. Найдите время, чтобы разобраться в этом. Это время никогда не тратится зря.
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
Проверяем DNS-записи при помощи PowerShell
Данный метод не является заменой привычным утилитам, например, nslookup, но он показывает возможности PowerShell и будет полезен всем, кто использует данный язык для автоматизации или изучает его.
Для разрешения доменных имен в PowerShell есть командлет Resolve-DnsName, использовать его достаточно просто, полный синтаксис команды выглядит так:
Но его можно упростить:
Ответ зависит от типа записи, для A вы просто получите адрес, а для CNAME результатом будет доменное имя, на которое ссылается запись. Ниже будет приведена информация о полученном доменном имени и разрешение его в IP-адрес.
Это довольно тонкий момент, потому что тот же nslookup всегда выводит второй строкой адрес, здесь же результатом работы может быть как адрес, так и иное доменное имя.
При этом, учитывая объектную структуру PowerShell, такой результат легче поддается разбору и анализу, также сразу будет указан тип записи в отдельном поле.
Для получения записей других типов дополнительно используйте ключ:
Результатом вывода для MX, если записи настроены правильно, вы получите одно или несколько доменных имен. Их разрешение в IP-адреса будет приведено ниже в выводе.
Если вам нужно получить результат от определенного сервера, то добавьте ключ:
А теперь несколько полезных опций, которые могут пригодиться при диагностике и разрешении проблем:
Данный ключ предписывает выполнить DNS-запрос игнорируя файлы hosts, локальный кеш, широковещательные протоколы и т.д.
Наоборот, выдаст запрос из локального кеша, что полезно для диагностики, если есть подозрения на неверную работу кеша.
Указанный ключ проигнорирует локальный файл hosts, его следует использовать если есть подозрение, что указанный домен переназначен локально.
Это далеко не все возможности командлета, а только самые полезные. Больше информации вы можете найти в документации: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname?view=windowsserver2022-ps
Данный метод не является заменой привычным утилитам, например, nslookup, но он показывает возможности PowerShell и будет полезен всем, кто использует данный язык для автоматизации или изучает его.
Для разрешения доменных имен в PowerShell есть командлет Resolve-DnsName, использовать его достаточно просто, полный синтаксис команды выглядит так:
Resolve-DnsName -Name "example.com"
Но его можно упростить:
Resolve-DnsName example.com
Ответ зависит от типа записи, для A вы просто получите адрес, а для CNAME результатом будет доменное имя, на которое ссылается запись. Ниже будет приведена информация о полученном доменном имени и разрешение его в IP-адрес.
Это довольно тонкий момент, потому что тот же nslookup всегда выводит второй строкой адрес, здесь же результатом работы может быть как адрес, так и иное доменное имя.
При этом, учитывая объектную структуру PowerShell, такой результат легче поддается разбору и анализу, также сразу будет указан тип записи в отдельном поле.
Для получения записей других типов дополнительно используйте ключ:
Resolve-DnsName example.com -Type MX
Результатом вывода для MX, если записи настроены правильно, вы получите одно или несколько доменных имен. Их разрешение в IP-адреса будет приведено ниже в выводе.
Если вам нужно получить результат от определенного сервера, то добавьте ключ:
Resolve-DnsName example.com -Type MX -Server 8.8.8.8
А теперь несколько полезных опций, которые могут пригодиться при диагностике и разрешении проблем:
Resolve-DnsName example.com -DnsOnly
Данный ключ предписывает выполнить DNS-запрос игнорируя файлы hosts, локальный кеш, широковещательные протоколы и т.д.
Resolve-DnsName example.com -CacheOnly
Наоборот, выдаст запрос из локального кеша, что полезно для диагностики, если есть подозрения на неверную работу кеша.
Resolve-DnsName example.com -NoHostsFile
Указанный ключ проигнорирует локальный файл hosts, его следует использовать если есть подозрение, что указанный домен переназначен локально.
Это далеко не все возможности командлета, а только самые полезные. Больше информации вы можете найти в документации: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname?view=windowsserver2022-ps
С Днем радио!!!
Сегодня мой профессиональный праздник и не только мой, но и многих коллег, особенно старшего возраста.
Это сейчас путь в IT открыт сразу и напрямую, в наше время путь к вычислительной технике начинался с радиолюбительства и программируемых калькуляторов.
Позже все это плавно перетекало в наиболее близкие профессии, связанные с электроникой. А электроника в свое время была неразлучно связана с связью (вот такой вот каламбур вышел).
И, следует сказать, радиолюбительское прошлое и профильное образование связиста сильно пригодилось впоследствии. Прежде всего инженерным мышлением, умением читать схемы и навыками диагностики и выявления неисправностей.
Появившиеся позднее компьютеры кто-то сделал помощниками в инженерных расчетах, а кто-то связал с ними свою профессию.
Поэтому всех причастных, настоящих и бывших связистов, хотя связисты, а тем более радиолюбители, бывшими не бывают, с праздником!
🥃🥃🥃
Сегодня мой профессиональный праздник и не только мой, но и многих коллег, особенно старшего возраста.
Это сейчас путь в IT открыт сразу и напрямую, в наше время путь к вычислительной технике начинался с радиолюбительства и программируемых калькуляторов.
Позже все это плавно перетекало в наиболее близкие профессии, связанные с электроникой. А электроника в свое время была неразлучно связана с связью (вот такой вот каламбур вышел).
И, следует сказать, радиолюбительское прошлое и профильное образование связиста сильно пригодилось впоследствии. Прежде всего инженерным мышлением, умением читать схемы и навыками диагностики и выявления неисправностей.
Появившиеся позднее компьютеры кто-то сделал помощниками в инженерных расчетах, а кто-то связал с ними свою профессию.
Поэтому всех причастных, настоящих и бывших связистов, хотя связисты, а тем более радиолюбители, бывшими не бывают, с праздником!
🥃🥃🥃
Как полностью удалить PPA и восстановить состояние системы
Одним из нововведений Ubuntu стала система персональных архивов пакетов (Personal Package Arhive - PPA), которые позволяли разработчикам легко создавать собственные репозитории, а пользователям их подключать и использовать.
В те времена это был огромный шаг вперед и сильно продвинул Ubuntu как простую и удобную в эксплуатации Linux систему.
Но в использовании PPA кроме очевидных плюсов есть столь же очевидные минусы. А именно – это репозиторий, а любой сторонний репозиторий это отличный шанс нарушить стабильную работу системы.
Вместе с нужной вам программой из PPA могут обновиться какие-то системные библиотеки или быть заменены какие-то другие компоненты системы, что может привести к самым различным последствиям.
Мы, конечно, можем отключить PPA-репозиторий, но только проблемы это не решает, установленные им пакеты останутся в системе и далеко не факт, что простое их удаление вам поможет.
Для того, чтобы не только полностью удалить PPA-репозиторий, но и полностью восстановить состояние системы предназначена утилита
Применять ее очень просто, достаточно указать наименование PPA в формате:
Это стандартный формат и если вы добавляли PPA командой:
То для полного удаления и восстановления используйте:
Если же вы не знаете точного имени PPA, то получить его можно из адреса репозитория, найти файлы с такими адресами вы можете в
Интересующая нас информация находится сразу за
Несмотря на то, что данная утилита позволяет нам достаточно просто откатить все изменения внесенные PPA следует понимать, что PPA – это достаточно опасный способ установки стороннего ПО и на сегодняшний день существуют современные и безопасные варианты, такие как Snap или Flatpak.
Одним из нововведений Ubuntu стала система персональных архивов пакетов (Personal Package Arhive - PPA), которые позволяли разработчикам легко создавать собственные репозитории, а пользователям их подключать и использовать.
В те времена это был огромный шаг вперед и сильно продвинул Ubuntu как простую и удобную в эксплуатации Linux систему.
Но в использовании PPA кроме очевидных плюсов есть столь же очевидные минусы. А именно – это репозиторий, а любой сторонний репозиторий это отличный шанс нарушить стабильную работу системы.
Вместе с нужной вам программой из PPA могут обновиться какие-то системные библиотеки или быть заменены какие-то другие компоненты системы, что может привести к самым различным последствиям.
Мы, конечно, можем отключить PPA-репозиторий, но только проблемы это не решает, установленные им пакеты останутся в системе и далеко не факт, что простое их удаление вам поможет.
Для того, чтобы не только полностью удалить PPA-репозиторий, но и полностью восстановить состояние системы предназначена утилита
ppa-purge, которая входит в стандартный репозиторий Ubuntu.Применять ее очень просто, достаточно указать наименование PPA в формате:
ppa:user_name/ppa_name
Это стандартный формат и если вы добавляли PPA командой:
add-apt-repository ppa:andrew-crew-kuznetsov/xneur-stable
То для полного удаления и восстановления используйте:
ppa-purge ppa:andrew-crew-kuznetsov/xneur-stable
Если же вы не знаете точного имени PPA, то получить его можно из адреса репозитория, найти файлы с такими адресами вы можете в
/etc/apt/sources.list.d, в нашем случае там будет:https://ppa.launchpadcontent.net/andrew-crew-kuznetsov/xneur-stable/ubuntu/ jammy main
Интересующая нас информация находится сразу за
ppa.launchpadcontent.net, в нашем случае это andrew-crew-kuznetsov/xneur-stable.Несмотря на то, что данная утилита позволяет нам достаточно просто откатить все изменения внесенные PPA следует понимать, что PPA – это достаточно опасный способ установки стороннего ПО и на сегодняшний день существуют современные и безопасные варианты, такие как Snap или Flatpak.
Алиасы в PowerShell
Многие, кто только начинает изучать PowerShell, особенно перейдя из мира Linux, жалуются на его многословность, что может быть неудобно, если вы используете PS непосредственно для администрирования системы.
Да, это так, но этому есть свои основания.
Классические UNIX-оболочки создавались в те далекие и светлые времена, когда компьютеры были большие, объемы памяти маленькие, а скорости передачи данных – медленные. Все это заставляло биться буквально за каждый байт.
Кроме того, в те времена не было ни интернета с гуглом, ни разных синтаксис-помощников, поэтому команды старались делать попроще, чтобы запоминать было легче, пренебрегая удобством чтения кода и наглядной очевидностью.
Да, bash прост, но прост для того, кто в нем постоянно работает. Если это не так, то возможны разные веселые, или не очень, затруднения.
Например, команда:
Еще вполне читабельна и если мы помним, что такое grep, то без труда догадаемся, что мы ищем строку "
И если вы не помните синтаксис grep вам придется непросто. Особенно если нужно изменить часть команды.
Поэтому PowerShell, который разрабатывался значительно позже, обильно полили синтаксическим сахаром, справедливо предполагая, что люди тоже могут читать программы. И не только могут, но и будут.
Поэтому тот же аналог grep в PowerShell выглядит так:
Да, многословно, но даже далекий от PowerShell человек поймет, что мы выбираем строки, содержащие текст
И если мы занимаемся написанием скриптов, то такая многословность нам только в плюс, так как сильно облегчает читаемость кода человеком.
А скрипты в голом блокноте давно уже никто не пишет, есть удобные среды разработки с автодополнением, подсветкой синтаксиса, синтаксис-помощниками и прочими плюшками.
Но как быть, если мы используем PowerShell для административных нужд, каждый раз набирать полное имя команды и ключи в консоли, даже с автодополнением, может быть утомительно.
А вот как раз для этого придумали алиасы. Полный список алиасов команд PowerShell можно посмотреть, выполнив команду:
Если нас интересует конкретная команда, то следует набрать:
А если, наоборот, расшифровать алиас, то следует выполнить:
Также можно создавать свои алиасы, для этого используйте команду:
Таким образом мы легко можем настроить среду согласно своих привычек или просто писать в привычном стиле:
А для тех, кто свои лучше годы отдал работе с Windows, напоминаем, что PowerShell давно доступен и на платформе Linux.
Многие, кто только начинает изучать PowerShell, особенно перейдя из мира Linux, жалуются на его многословность, что может быть неудобно, если вы используете PS непосредственно для администрирования системы.
Да, это так, но этому есть свои основания.
Классические UNIX-оболочки создавались в те далекие и светлые времена, когда компьютеры были большие, объемы памяти маленькие, а скорости передачи данных – медленные. Все это заставляло биться буквально за каждый байт.
Кроме того, в те времена не было ни интернета с гуглом, ни разных синтаксис-помощников, поэтому команды старались делать попроще, чтобы запоминать было легче, пренебрегая удобством чтения кода и наглядной очевидностью.
Да, bash прост, но прост для того, кто в нем постоянно работает. Если это не так, то возможны разные веселые, или не очень, затруднения.
Например, команда:
grep error error.log Еще вполне читабельна и если мы помним, что такое grep, то без труда догадаемся, что мы ищем строку "
error" в файле error.log. Но расширение не является обязательным атрибутом файла и поэтому мы вполне можем встретить:grep error error
И если вы не помните синтаксис grep вам придется непросто. Особенно если нужно изменить часть команды.
Поэтому PowerShell, который разрабатывался значительно позже, обильно полили синтаксическим сахаром, справедливо предполагая, что люди тоже могут читать программы. И не только могут, но и будут.
Поэтому тот же аналог grep в PowerShell выглядит так:
Select-String -Pattern "error" -Path .\errorДа, многословно, но даже далекий от PowerShell человек поймет, что мы выбираем строки, содержащие текст
“error” из файла .\error. И если мы занимаемся написанием скриптов, то такая многословность нам только в плюс, так как сильно облегчает читаемость кода человеком.
А скрипты в голом блокноте давно уже никто не пишет, есть удобные среды разработки с автодополнением, подсветкой синтаксиса, синтаксис-помощниками и прочими плюшками.
Но как быть, если мы используем PowerShell для административных нужд, каждый раз набирать полное имя команды и ключи в консоли, даже с автодополнением, может быть утомительно.
А вот как раз для этого придумали алиасы. Полный список алиасов команд PowerShell можно посмотреть, выполнив команду:
Get-AliasЕсли нас интересует конкретная команда, то следует набрать:
Get-Alias -Definition Select-StringА если, наоборот, расшифровать алиас, то следует выполнить:
Get-Alias slsТакже можно создавать свои алиасы, для этого используйте команду:
Set-Alias -Name grep -Value Select-StringТаким образом мы легко можем настроить среду согласно своих привычек или просто писать в привычном стиле:
sls error errorА для тех, кто свои лучше годы отдал работе с Windows, напоминаем, что PowerShell давно доступен и на платформе Linux.
И еще немного про алиасы в PowerShell
PowerShell предлагает большой набор встроенных алиасов, про них мы подробно писали в нашей прошлой заметке.
И предназначены они сугубо для интерактивного использования внутри командной оболочки, т.е. для сокращения руками вводимых команд и упрощения их запоминания, ключи, между прочим, тоже успешно можно пропускать, если располагать опции в надлежащем порядке.
Это как раз решает проблему многословности PowerShell при интерактивном использовании.
Можно ли создавать и применять в проде свои алиасы? Можно и даже нужно, если использовать их по назначению, а именно для интерактивной работы в консоли.
Созданные алиасы без проблем можно выгружать и загружать на другой машине, для этого следует использовать команды
Поэтому у грамотного администратора не будет проблемы с созданными алиасами на новой системе, равно как и не будет их у человека, про данные алиасы не знающего.
А вот чего не стоит делать с алиасами не при каких обстоятельствах – это тащить их в скрипты. Скрипты давно никто на коленке в чистом блокноте не пишет, а любая среда разработки как минимум содержит подсказки и автодополнения, что позволяет быстро и удобно писать код с использованием полного синтаксиса.
Также в скриптах следует обязательно указывать все ключи, даже если их можно пропустить. Это не повлияет на работу, но положительно скажется на читабельности кода вашими коллегами или вами через некоторое время.
И, следует отметить, что многие упреки в неудобности и многословности PowerShell проистекают именно от незнания и попытки напрямую перенести на него предыдущий пользовательский опыт, не изучая возможности языка.
А возможность использовать короткую и немногословную нотацию у него есть, для чего нужно просто ознакомиться со списком встроенных алиасов.
PowerShell предлагает большой набор встроенных алиасов, про них мы подробно писали в нашей прошлой заметке.
И предназначены они сугубо для интерактивного использования внутри командной оболочки, т.е. для сокращения руками вводимых команд и упрощения их запоминания, ключи, между прочим, тоже успешно можно пропускать, если располагать опции в надлежащем порядке.
Это как раз решает проблему многословности PowerShell при интерактивном использовании.
Можно ли создавать и применять в проде свои алиасы? Можно и даже нужно, если использовать их по назначению, а именно для интерактивной работы в консоли.
Созданные алиасы без проблем можно выгружать и загружать на другой машине, для этого следует использовать команды
Export-Alias и Import-Alias.Поэтому у грамотного администратора не будет проблемы с созданными алиасами на новой системе, равно как и не будет их у человека, про данные алиасы не знающего.
А вот чего не стоит делать с алиасами не при каких обстоятельствах – это тащить их в скрипты. Скрипты давно никто на коленке в чистом блокноте не пишет, а любая среда разработки как минимум содержит подсказки и автодополнения, что позволяет быстро и удобно писать код с использованием полного синтаксиса.
Также в скриптах следует обязательно указывать все ключи, даже если их можно пропустить. Это не повлияет на работу, но положительно скажется на читабельности кода вашими коллегами или вами через некоторое время.
И, следует отметить, что многие упреки в неудобности и многословности PowerShell проистекают именно от незнания и попытки напрямую перенести на него предыдущий пользовательский опыт, не изучая возможности языка.
А возможность использовать короткую и немногословную нотацию у него есть, для чего нужно просто ознакомиться со списком встроенных алиасов.
Учимся работать со Snap
Почему-то, как только речь заходит про Snap у многих системных администраторов включается режим «не читал – но осуждаю» при котором Snap наделяется массой отрицательных качеств и чуть ли не подлежит немедленному выпиливанию из системы.
В тоже время Snap является универсальным форматом пакетов, созданным компанией Canonical первоначально для Ubuntu, но получившим широкое распространение и в других дистрибутивах.
Главной особенностью snap-пакетов является их самодостаточность, они содержат как нужное приложение, так и все основные зависимости к нему, что ускоряет распространение приложений и снижает возможные конфликты с другим ПО.
Поэтому перед тем как «осуждать» следует все таки ознакомиться с данной технологией подробнее.
https://interface31.com.ru/tech_it/2022/11/linux-nachinayushhim-uchimsya-rabotat-so-snap.html
Почему-то, как только речь заходит про Snap у многих системных администраторов включается режим «не читал – но осуждаю» при котором Snap наделяется массой отрицательных качеств и чуть ли не подлежит немедленному выпиливанию из системы.
В тоже время Snap является универсальным форматом пакетов, созданным компанией Canonical первоначально для Ubuntu, но получившим широкое распространение и в других дистрибутивах.
Главной особенностью snap-пакетов является их самодостаточность, они содержат как нужное приложение, так и все основные зависимости к нему, что ускоряет распространение приложений и снижает возможные конфликты с другим ПО.
Поэтому перед тем как «осуждать» следует все таки ознакомиться с данной технологией подробнее.
https://interface31.com.ru/tech_it/2022/11/linux-nachinayushhim-uchimsya-rabotat-so-snap.html
Работа с репозиториями в Debian
Как известно программное обеспечение в Linux устанавливается из централизованных хранилищ – репозиториев. Для работы с ними используется специальное ПО – пакетный менеджер.
В Debian и основанных на нем дистрибутивах это APT. Список репозиториев находится в
Но не всегда набор программ в официальном репозитории является достаточным. Какое-то ПО может отсутствовать, какое-то иметь слишком старые версии. В этом случае обычно подключаются дополнительные репозитории содержащие нужные версии программ.
Добавить их можно по-разному, можно внести записи прямо в
Более подробно можно прочитать в нашей статье:
▫️ Linux - начинающим. Управление пакетами в Debian и Ubuntu
Но следует понимать, что добавление сторонних репозиториев – это потенциально опасная операция и один из самых доступных способов сломать систему.
Поэтому всегда смотрите что на самом деле будет установлено вместе с новым пакетом, проверив его зависимости и посмотрев их источники.
Также можете смоделировать процесс установки использовав ключ
А вообще, если речь идет о небольших программах или пользовательском софте проверить нет ли нужного пакета в формате Snap или Flatpack. В этом случае все нужное пакет принесет с собой и риск сломать систему минимальный.
Про работу Snap читайте:
▫️ Linux - начинающим. Учимся работать со Snap
Еще один распространенный сценарий – это использование репозиториев предыдущего выпуска для получения пакетов, которые требуются некоторому софту, чаще коммерческому, по зависимостям, но отсутствуют в текущей версии.
Чаще всего это безопасно, то есть свои особенности, в частности с возможным обновлением пакета. Можно, конечно, поставить ему HOLD, но это не всегда правильно, особенно если пакет продолжает получать обновления в рамках предыдущего выпуска.
Более правильно в таких случаях использовать технологию APT Pinning, подробнее здесь:
▫️ Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Ну и наконец, если вы все-таки не вняли первоначальному совету и превратили
Можно спросить у Гугла, можно подсмотреть на другой аналогичной системе, но зачем, если можно восстановить его содержимое одной командой:
Кстати, в той же директории есть оригиналы и других важных файлов из директории
Как известно программное обеспечение в Linux устанавливается из централизованных хранилищ – репозиториев. Для работы с ними используется специальное ПО – пакетный менеджер.
В Debian и основанных на нем дистрибутивах это APT. Список репозиториев находится в
/etc/apt/sources.list. Но не всегда набор программ в официальном репозитории является достаточным. Какое-то ПО может отсутствовать, какое-то иметь слишком старые версии. В этом случае обычно подключаются дополнительные репозитории содержащие нужные версии программ.
Добавить их можно по-разному, можно внести записи прямо в
/etc/apt/sources.list, но в приличном обществе принято создавать отдельные файлы с расширением .list в /etc/apt/sources.list.d. Это позволяет более гибко управлять репозиториями, чтобы отключить не нужные достаточно просто удалить файл или сменить его расширение.Более подробно можно прочитать в нашей статье:
▫️ Linux - начинающим. Управление пакетами в Debian и Ubuntu
Но следует понимать, что добавление сторонних репозиториев – это потенциально опасная операция и один из самых доступных способов сломать систему.
Поэтому всегда смотрите что на самом деле будет установлено вместе с новым пакетом, проверив его зависимости и посмотрев их источники.
Также можете смоделировать процесс установки использовав ключ
-s:apt install имя_пакета -s
А вообще, если речь идет о небольших программах или пользовательском софте проверить нет ли нужного пакета в формате Snap или Flatpack. В этом случае все нужное пакет принесет с собой и риск сломать систему минимальный.
Про работу Snap читайте:
▫️ Linux - начинающим. Учимся работать со Snap
Еще один распространенный сценарий – это использование репозиториев предыдущего выпуска для получения пакетов, которые требуются некоторому софту, чаще коммерческому, по зависимостям, но отсутствуют в текущей версии.
Чаще всего это безопасно, то есть свои особенности, в частности с возможным обновлением пакета. Можно, конечно, поставить ему HOLD, но это не всегда правильно, особенно если пакет продолжает получать обновления в рамках предыдущего выпуска.
Более правильно в таких случаях использовать технологию APT Pinning, подробнее здесь:
▫️ Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Ну и наконец, если вы все-таки не вняли первоначальному совету и превратили
/etc/apt/sources.list непонятно во что и все сломали, либо наоборот решили навести порядок, то может стать вопрос: а где взять исходное содержимое этого файла.Можно спросить у Гугла, можно подсмотреть на другой аналогичной системе, но зачем, если можно восстановить его содержимое одной командой:
cat /usr/share/doc/apt/examples/sources.list > /etc/apt/sources.list
Кстати, в той же директории есть оригиналы и других важных файлов из директории
/etc/apt, рекомендуем ознакомиться.