Как-то прочёл маленькую книженцию про PowerShell, там был раздел "щелчок-по-носу" мне линуксоиду: в PowerShell всё объекты, хоть на экране, естественно, мы видим текст. НО PowerShell - это не cmd/bash, где ты устраиваешь с помощью конвееров "переливашки текста", перепроверяешь скрипты при серьёзных обновлениях сервера ("не поплыл ли вывод?"), пытаешься grep'пить нужное и т.д. PowerShell действительно крутая штука и админам windows систем - обязателен к изучению.
Всё хорошо - реально (!), только если помнить главный минус любой SDS системы что сеть - это "не быстро". Это так же автоматически означает, что дисковый I/O у виртуальных машин никогда не может быть лучше поверх классических СХД. Вечно стараться приближаться к их показателям IOPS, latency и т.д., но никогда не достигать. Лучше всего это расписано в статье
На практике же, если задача требует сервер с хорошими показателями на запись, то просто такое решение развёртывается на отдельных физических серверах. Другими словами, не зацикливаться на SDS и не решать ею абсолютно все вопросы.
Так как Proxmox VE + Ceph - это open source, дающий shared storage, то в целом получаешь много админских плюшек (переезд в онлайн ВМ с ноды на ноду, "ночной администратор" High Availability) и даром, не считая своих знаний и труда.
В SDS Ceph есть возможность создавать пулы типы erasure code, что оптимально под надёжное хранение холодных данных с минимальными "потерями" дискового пространства. Такое решение тоже имеет право на существование.
Не помню точно у кого есть Web UI в дополнение к обычному GUI и CLI. Но, возможно, вашу задачу осилят локальные поисковики. Сам активно использовал Recoll, но перебрался на DocFetcher. У меня схожая задача - в огромной массе документов, в том числе pdf, часто приходится искать нужную информацию.
С благодарностью вспоминаю Хакер и рубрику Visual Hack. А спустя годы, в июне 2010 года даже была опубликована моя статья Ускорение Ubuntu, в журнале она шла как "Операция Оптимизация". Каёф =)
Увлёкся нейронными сетями, в том смысле, что запускаю их на своих мощностях и пытаюсь разбираться в их сферах применимости. В коллекции много нейронных сетей и среди них есть SwinIR, которая умеет убирать артефакты сжатия JPEG (JPEG Compression Artifact Reduction), НО только для gray изображений.
Для удобства работы с grep в журнале должна быть в идеале 1 строка на 1 событие, которое вас интересует. Многие программы обладают параметрами по типу Nmap (-oG : Grepable format), чтобы их вывод легче было фильтровать. Сложности начинают возникать, когда событие "размазано" в журнале по разным строкам, которые могут быть "разбавлены" другими строками.
Благодаря мощности всего стека ELK можно красиво парсить даже multiline журналы, для примера Postfix. Лично я начал отказываться от grep текстовых журналов и вначале на базе ELK сделал единый remote syslog. Если вывод какой-то службы особо важен и интересен, то его выделяю в отдельный индекс и не ленюсь написать grok парсер для разбивки по полям: журнал bind9 запросов, postfix(SMTP), dovecot(POP3, IMAP), kaspersky linux mail server.
Помогите кто знает - как на своих мощностях запустить Kandinsky и Surrealist? Malevich запустил по примерам на GitHub проекта, хоть и с трудом, а вот Kandinsky даже нет намёка или кусочков кода Python.
casync используется "под капотом" в проекте Proxmox Backup Server, поэтому виртуальные машины быстро архивируются за счёт передачи только изменений и мало занимают дискового пространства за счёт огромного коэффициента дедупликации.
Не во всех конторах серверов столько что обязательны инструменты оркестровки типа ansible, а перед этим Git, череда тестов и CI/CD. Много админов используют лишь SSH и работу на сервере при проблемах или в случаях каких-либо изменений.
У меня есть скрипты с 2004 года, а это уже почти 20 лет и там не нужен Питон от слова совсем. Bash - это прежде всего простота и быстрая возможность изменить/добавить. В консоли сервера в редакторах вы ещё настраиваете замену tab на череду пробелов, чтобы не сломать python скрипт (возможно не ваш), а я уже поправил свой bash скрипт и он снова в строю.
Извините меня админа, но топорные bash скрипты автоматизации работают годами. Нет ни времени ни желания при выходе новой версии того же Питона переписывать код вчера с 2 на 3 версию, а завтра с 3 на 4 и т.д.
Всегда настораживают жёстко (вшитые|указанные) числа типа chown 36:36. Вы гарантируете что у всех UID и GID 36 указывает на верного для вас пользователя и группу? Почему не используется имя?
Не поставлена, а поставили. Это закономерный итог, в том числе такой сильной зависимости нашего ИТ от западных технологий. Мало, очень мало есть в ИТ русского. Что есть - повод для гордости (без сарказма), но этого мало.
Какие-то странные люди, упомянутые в статье. Технологии Network Address Translation (NAT) и Classless Inter-Domain Routing (CIDR) как раз и вводились, чтобы "спасти" IPv4. Их задача была затормозить быстрое исчерпание 2^32 IPv4. Затормозили ли они тем самым переход на IPv6? Безусловно! Чем острее проблема, тем быстрее люди шевелятся в поисках её окончательного решения без костылей, чем и является NAT.
>У многих из них установлены простые пароли, которые не защищают от утечки их персональных данных и, например, изменения банковских реквизитов для госвыплат.
А как специалисты ГосУслуг допускают ввод простых паролей?
Как-то прочёл маленькую книженцию про PowerShell, там был раздел "щелчок-по-носу" мне линуксоиду: в PowerShell всё объекты, хоть на экране, естественно, мы видим текст. НО PowerShell - это не cmd/bash, где ты устраиваешь с помощью конвееров "переливашки текста", перепроверяешь скрипты при серьёзных обновлениях сервера ("не поплыл ли вывод?"), пытаешься grep'пить нужное и т.д. PowerShell действительно крутая штука и админам windows систем - обязателен к изучению.
Более подробно и доказательно в разделе "О тексте, разборе текста и объектах"
https://disk.yandex.ru/i/Pfe6iZZUXb4NZA
Используем гиперконвергентную архитектуру на базе Proxmox VE + Ceph.
https://pve.proxmox.com/wiki/Hyper-converged_Infrastructure
Всё хорошо - реально (!), только если помнить главный минус любой SDS системы что сеть - это "не быстро". Это так же автоматически означает, что дисковый I/O у виртуальных машин никогда не может быть лучше поверх классических СХД. Вечно стараться приближаться к их показателям IOPS, latency и т.д., но никогда не достигать. Лучше всего это расписано в статье
https://yourcmc.ru/wiki/index.php?title=Производительность_Ceph
На практике же, если задача требует сервер с хорошими показателями на запись, то просто такое решение развёртывается на отдельных физических серверах. Другими словами, не зацикливаться на SDS и не решать ею абсолютно все вопросы.
Так как Proxmox VE + Ceph - это open source, дающий shared storage, то в целом получаешь много админских плюшек (переезд в онлайн ВМ с ноды на ноду, "ночной администратор" High Availability) и даром, не считая своих знаний и труда.
В SDS Ceph есть возможность создавать пулы типы erasure code, что оптимально под надёжное хранение холодных данных с минимальными "потерями" дискового пространства. Такое решение тоже имеет право на существование.
https://docs.ceph.com/en/latest/rados/operations/erasure-code/
Покупаете свой сервер и вперёд. Никто и ничто вам не мешает. Весь трафик ваш. И мусор сами отсеете.
Согласен, у вас не просто поиск и всё. Тогда удачи вам в проекте с Мантикорой.
Не помню точно у кого есть Web UI в дополнение к обычному GUI и CLI. Но, возможно, вашу задачу осилят локальные поисковики. Сам активно использовал Recoll, но перебрался на DocFetcher. У меня схожая задача - в огромной массе документов, в том числе pdf, часто приходится искать нужную информацию.
https://en.wikipedia.org/wiki/List_of_search_engines#Desktop_search_engines
С благодарностью вспоминаю Хакер и рубрику Visual Hack. А спустя годы, в июне 2010 года даже была опубликована моя статья Ускорение Ubuntu, в журнале она шла как "Операция Оптимизация". Каёф =)
Увлёкся нейронными сетями, в том смысле, что запускаю их на своих мощностях и пытаюсь разбираться в их сферах применимости. В коллекции много нейронных сетей и среди них есть SwinIR, которая умеет убирать артефакты сжатия JPEG (JPEG Compression Artifact Reduction), НО только для gray изображений.
https://github.com/JingyunLiang/SwinIR
http://vasilisc.com/learn-neural-networks
Это делается в ELK не регулярными выражениями, а агрегирующим фильтром
https://www.elastic.co/guide/en/logstash/current/plugins-filters-aggregate.html
Для удобства работы с grep в журнале должна быть в идеале 1 строка на 1 событие, которое вас интересует. Многие программы обладают параметрами по типу Nmap (-oG : Grepable format), чтобы их вывод легче было фильтровать. Сложности начинают возникать, когда событие "размазано" в журнале по разным строкам, которые могут быть "разбавлены" другими строками.
Благодаря мощности всего стека ELK можно красиво парсить даже multiline журналы, для примера Postfix. Лично я начал отказываться от grep текстовых журналов и вначале на базе ELK сделал единый remote syslog. Если вывод какой-то службы особо важен и интересен, то его выделяю в отдельный индекс и не ленюсь написать grok парсер для разбивки по полям: журнал bind9 запросов, postfix(SMTP), dovecot(POP3, IMAP), kaspersky linux mail server.
http://vasilisc.com/postfix-logs-2-elasticsearch
http://vasilisc.com/grok-pattern-kaspersky-linux-mail-server
В телеграмме автор указал на то что в свободном доступе пока нет моделей Kandinsky. Нужно подождать до конца лета.
Помогите кто знает - как на своих мощностях запустить Kandinsky и Surrealist? Malevich запустил по примерам на GitHub проекта, хоть и с трудом, а вот Kandinsky даже нет намёка или кусочков кода Python.
casync используется "под капотом" в проекте Proxmox Backup Server, поэтому виртуальные машины быстро архивируются за счёт передачи только изменений и мало занимают дискового пространства за счёт огромного коэффициента дедупликации.
https://pbs.proxmox.com/docs/pxar-tool.html
Не во всех конторах серверов столько что обязательны инструменты оркестровки типа ansible, а перед этим Git, череда тестов и CI/CD. Много админов используют лишь SSH и работу на сервере при проблемах или в случаях каких-либо изменений.
bash =)
У меня есть скрипты с 2004 года, а это уже почти 20 лет и там не нужен Питон от слова совсем. Bash - это прежде всего простота и быстрая возможность изменить/добавить. В консоли сервера в редакторах вы ещё настраиваете замену tab на череду пробелов, чтобы не сломать python скрипт (возможно не ваш), а я уже поправил свой bash скрипт и он снова в строю.
Извините меня админа, но топорные bash скрипты автоматизации работают годами. Нет ни времени ни желания при выходе новой версии того же Питона переписывать код вчера с 2 на 3 версию, а завтра с 3 на 4 и т.д.
Всегда настораживают жёстко (вшитые|указанные) числа типа chown 36:36. Вы гарантируете что у всех UID и GID 36 указывает на верного для вас пользователя и группу? Почему не используется имя?
Не поставлена, а поставили. Это закономерный итог, в том числе такой сильной зависимости нашего ИТ от западных технологий. Мало, очень мало есть в ИТ русского. Что есть - повод для гордости (без сарказма), но этого мало.
Какие-то странные люди, упомянутые в статье. Технологии Network Address Translation (NAT) и Classless Inter-Domain Routing (CIDR) как раз и вводились, чтобы "спасти" IPv4. Их задача была затормозить быстрое исчерпание 2^32 IPv4. Затормозили ли они тем самым переход на IPv6? Безусловно! Чем острее проблема, тем быстрее люди шевелятся в поисках её окончательного решения без костылей, чем и является NAT.
>У многих из них установлены простые пароли, которые не защищают от утечки их персональных данных и, например, изменения банковских реквизитов для госвыплат.
А как специалисты ГосУслуг допускают ввод простых паролей?
Много лет внутри ВМ используем nobarrier, но лучше почитать сначала доводы против.
https://habr.com/ru/post/471906/