https://www.rosbalt.ru/like/2022/09/12/1973727.html
Китайская компания назначила своим генеральным директором робота. Организация заявила, что он будет действовать как «аналитический инструмент» для поддержки принятия решений.
Юристы наверно, просто в шоке ? =)
Предлагаю составить список уязвимостей.
Только что звонили жулье (есть запись разговора), предлагали поменять номер в Сбере. Я позвонил в Сбер, спросил можно ли наложить запрет на такую замену телефона SMS банка по телефону? Эти клоуны вместо ответа на вопрос начали объяснять, что без доступа к персональной инфе такая замена невозможна, мои аргументы относительно возможности кражи персональных данных проигнорировали. Кражи голосовых сообщений вероятно тоже.
Давно Сбер превратился из совкового цирка Шапито в Шапито «Нового прекрасного мира»?
IMHO из старого совкоСбера «где счет открывали, там и получайте» жуликам стырить деньги было на порядок сложнее =) Хотя это с какой стороны посмотреть, ведь по сути покупательскую способность людей в начале 90х обнулили всех сразу и одновременно.
Личный кабинет очень удобный и в целом уровень услуг неплохой, приятные офисы.
Жаль, что складывается впечатление об отсутствии отдела безопасности в Сбере, который бы заботился о клиентах. Или они в доле с жуликами?
Перемещено Dimez из security
Добрый вечер,
Прошу прощения за немного оффтоп, если это не совсем про Linux.
Раньше на AliExpress в поиске была галочка с бесплатным возвратом обратно (в случае обнаружения дефектов), а сейчас в поиске осталась только галочка с бесплатной доставкой сюда в РФ?
Как находить товары с бесплатным возвратом?
Перебрал десяток лотов из запроса Core2 Quad, ничего подходящего с гарантией манибэка не нашел :(
Перемещено Dimez из general
Вот тут что-то похожее, но вероятно небесплатное и не open source?
https://support.myoffice.ru/faq/mailion/v-chem-preimushchestva-mailion-po-sra...
- Построен с использованием микросервисной архитектуры и соответствует требованиям Cloud Native;
- Поддерживает отказоустойчивую работу до миллиона активных пользователей;
- Поддерживает распределенную архитектуру почтовой системы;
Вероятно его можно самостоятельно установить в IaaS в режиме высокой доступности? Кластер можно построить из серверов в нескольких удаленных датацентрах?
А есть ли уже готовый SaaS, где территориально распределенный почтовый кластер уже настроен? Как говорится, наливай, да пей :)
Наверно большинство крупных провайдеров типа Google, Microsoft, etc. работают как раз по такой схеме?
Пожалуйста, подскажите, существуют ли аналоги такого устройства:
http://adopt-zu.soroka.org.ua/ver8.html
?
Если не существуют, то как приобрести такое устройство в РФ? Через посредника в Украине?
Дорогой LOR,
Понимаю, что возможно этот топик вызовет очень разные чувства и эмоции у разных читателей, но все же интересно ваше мнение о моем мнении об онтопике. Написал основные свои мысли по этому поводу.
Выбор между SaaS, PaaS, IaaS, On-premises (локальная инфра).
Если ваша полиси безопасности позволяет, то по остальным критериям почти всегда нужно стремиться найти возможность использовать сначала предпочтительно SaaS, если не получится, то PaaS, и только уже потом IaaS, если не получается найти PaaS для вашего требуемого уровня кастомизации. Если компания не специализируется на предоставлении определенного вида сервиса типа SaaS или PaaS, то даже IT отделу лучше заняться более узкоспециализированными задачами из своей предметной области, чем пытаться поднимать подобные сервисы в своей инфре. Можно найти отличные готовые решения типа Yandex 360 или Google WorkSpace Business (не удивлюсь, если у них таким занят целый отдел или несколько отделов для каждого сложного сервиса).
Если вы надеетесь с помощью только отказоустойчивой облачной IaaS добиться отказоустойчивости своих приложений, то HA только инфры недостаточно для отказоустойчивости самого приложения, например из-за возможных багов в приложении, падении его частей из-за нагрузки, эксплойтов и т.п. Проще всего приобрести готовый SaaS уровня business у крупного облачного провайдера, где уже решены вопросы безопасности, HA в кластерах приложений, сохранности и приватности данных (хотя бы частично потому что полностью это очень труднодостижимо даже для провайдеров уровня Google, Amazon, Azure) и т.п. Какой бы надежный не был облачный провайдер, всегда необходимо обеспечить возможность перехода к другому и хранение регулярной бэкап реплики своих данных, иначе из-за критического сбоя провайдера или его изменившейся политики в области блокировки неугодных пользователей можно прийти к очень большим убыткам из-за остановки сервисов и утери своих данных.
При прочих равных условиях, включая намного больше факторов (особенно в области безопасности и High Availability), чем обычно учитывает среднестатистический администратор, SaaS обычно экономичнее других вариантов (PaaS, IaaS, etc.) почти всегда и особенно для случаев достижения высокой степени доступности на уровне 99.999% времени, потому что даже, чтобы нанять только опытных безопасников, которые смогут защитить сервер от зависаний из-за эксплойтов, от утечек данных (что нередко требует специального образования и оборудования в т.ч.) и т.п., стоит относительно дорого и требует относительно много времени для освоения, что обычно недоступно обычным админам без предварительной подготовки. Кроме того одного человека явно недостаточно для качественного администрирования хотя бы даже только одного вида сервиса и обеспечения доступности такого сервиса, нужно как минимум двое для подмены, и то это на пределе их возможностей и надежности системы, т.е. лучше больше для взаимозаменяемости, а это очень дорого при высоких требованиях к квалификации персонала.
Еще раз повторю, что абсолютно необходима взаимозаменяемость провайдеров и наличие регулярной локальной реплики данных облачного сервиса, иначе вы - заложник того или иного провайдера и находитесь в состоянии Vendor Lock со всеми вытекающими последствиями, включая геополитические.
Примеры SaaS: для популярных CMS типа Wordpress обычно можно найти SaaS или PaaS, удовлетворяющий всем требованиям. Для сайта визитки вполне достаточно SaaS, чьим наполнением справится копирайтер или в запущенных случаях эникей. Программисты занимаются программированием. Если программист занимается наполнением сайта, то это уже не программист, а офисный работник по набору текста, хорошо если он еще разбирается в PR и рекламе, что одновременно конечно большая редкость и бессмысленность при узкой специализации.
Пример IaaS: для сильно кастомизируемого сервиса почты можно использовать IRedMail docker container для развертывания в IaaS. Конечно, использование облачных сервисов возможно, только когда полиси безопасности компании разрешает использование облачных сервисов, но очень сомнительно, чтобы какая-то среднестатистическая компания могла самостоятельно обеспечить у себя защищенность данных от хакеров (не от спецслужб) выше, чем крупные облачные сервисы хотя бы из-за разницы в уровне квалификации их сотрудников.
Масштабирование (scaling).
Обычно проще (быстрее и предсказуемее) нарастить объемы виртуального сервера даже on premise, чем физического сервера, путем его миграции на другой уже заранее готовый более мощный хост (при наличии), чем пытаться оперативно проапгрейдить физический сервер. Аналогично относительно несложно масштабировать контейнеры, особенно с помощью автоматизированного оркестратора типа Kubernetes, но там еще к тому же появляется возможность упрощенного горизонтального масштабирования.
Не хочу всяких PulseAudio и т.п.
Хотелось бы c использованием только ALSA, snd-aloop и ffmpeg.
В принципе понятно, что нужно что-то похожее на:
Workstation: Player -> ALSA -> snd-aloop -> ffmpeg_N1 -> network
Remote Server (with Hardware Sound Card): network -> ffmpeg_N2 -> sound_card
Вопрос только в следующем, умеет ли ffmpeg работать в режиме подключения ffmpeg_N1 к ffmpeg_N2 в качестве клиента в терминологии TCP/IP ? Т.е. чтобы НЕ открывать порт stream сервера звука на workstation? Впрочем я все равно собираюсь потом использовать канал SSH для связи хостов, поэтому будет ли redirect через ssh -L или ssh -R не очень принципиально.
Т.е. меня интересует совет по ману:
https://manpages.ubuntu.com/manpages/kinetic/en/man1/ffmpeg-protocols.1.html
http://www.thg.ru/storage/20060110/Promise_SuperTrak_EX8350.html
https://www.nix.ru/autocatalog/controllers_promise/Promise-SuperTrak-EX8350-O...
https://forum.ixbt.com/topic.cgi?id=11:33192-3
Кто знает относительно старые многопортовые HBA или RAID с JBOD, которые поддерживают диски более 2TB? Хотя бы 4TB.
Кстати, если есть поддержка больше 2TB, это автоматически означает и поддержку 6-10TB в одном SATA порту тоже?
Аналогично raidz:
https://habr.com/ru/news/t/563442/
https://openzfs.github.io/openzfs-docs/Basic Concepts/dRAID Howto.html
Перемещено hobbit из general
Пожалуйста, подскажите, если JBOD диск относительно старого контроллера LSI SATA присоединить в качестве физического устройства к ZFS пулу, то можно ли потом этот пул импортировать на другом хосте с обычными SATA портами матплаты, которые ничего не знают ни про LSI RAID, ни про JBOD, etc.?
Найдет ли ZFS свои структуры данных на диске, который когда-то был подключен как JBOD, а теперь напрямую без вумного контроллера просто через SATA порт матплаты или HBA.
Доброго времени суток,
Ведь есть Linux WINE, зачем еще ЭТО?
https://en.wikipedia.org/wiki/ReactOS
Почему лучше не потратить ресурсы их кодеров на портирование некоторых полезных компонентов типа Desktop Environment из ReactOS на WINE или даже нативно прямиком на Linux (X11 или Wayland)? Чтобы такой DE, внешне почти неотличимый от WinXP, работал бы в связке с Linux ядром и WINE.
Т.е. чтобы Look & Feel у DE был точно такой же как у Windows, чтобы иконки программ можно было двигать по менюхе старта как в Win95-WinXP, надеюсь, хотя бы это ReactOS умеет?
Как думаете, при разделении, нарушается ли консистентность знаний одной стороны о другой?
Пожалуйста, подскажите какие-нибудь DIY проекты или недорогие (до $100) наборы или готовые устройства, подходящие для переделки, чтобы получить точный электронный термометр для диапазона температур от -10 до +20 (или шире) градусов.
Вероятно нужно использовать платиновый датчик (они относительно недорогие, например, на Авито).
Желательная точность хотя бы не менее, чем у жидкостного гигрометра ВИТ 1:
https://www.gradusniki.ru/cat/img/vlajnost/vit-1.html
вероятно, равная цене деления (0.2 °C) в случае поверенного экземпляра?
В идеале хотелось бы иметь возможность считывать показания нескольких датчиков с дисплея одноплатника и логировать их вместе с текущими GPS координатами на microSD карту.
Есть относительно дорогие готовые модели Testo: https://www.testo.ru/ru-RU/testo-176-t4/p/0572-1764 Но в них вроде нет GPS, хотя вероятно можно использовать совместно с другим GPS трэкером.
Кстати, видел простенькие электронные термометры с платиновым датчиком «для бани» по цене около 2-3 тыр за штуку, цена «деления» (возможно и точность тоже) вроде бы 0.1 °C?
https://market.yandex.ru/product--termometr-elektronnyi-tes-2pt-v-plastikovom...
https://www.ozon.ru/product/termometr-elektronnyy-tes-2pt-v-plastikovom-korpu...
Точность отображения температуры в диапазоне от –9,9 до +99,9°С, °С :0,1
Сделал скрипт для настройки бриджа для тестов и экспериментов:
DHCP Server <-> server---server_br <-> bridge
dhclient client1 <-> client1---client1_br <-> bridge
dhclient client2 <-> client2---client2_br <-> bridge
dhclient client3 <-> client3---client3_br <-> bridge
server, server_br, clientN, clientN_br - это имена интерфейсов veth (виртуальных «патчей»).
+ ifconfig -a
bond0: flags=5122<BROADCAST,MASTER,MULTICAST> mtu 1500
ether 46:5d:f3:67:fd:0b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether ca:4e:93:0d:08:a2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2 bytes 108 (108.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
client1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether a2:28:6b:ef:fc:90 txqueuelen 1000 (Ethernet)
RX packets 1 bytes 54 (54.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
client2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether f6:f7:dc:4d:38:36 txqueuelen 1000 (Ethernet)
RX packets 1 bytes 54 (54.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
client3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 76:5a:e7:30:2e:51 txqueuelen 1000 (Ethernet)
RX packets 1 bytes 54 (54.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
client1_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether ca:4e:93:0d:08:a2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 54 (54.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
client2_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether ca:5b:c7:5f:6b:8e txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 54 (54.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
client3_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether ea:3d:63:4a:9a:20 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 54 (54.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
ether 00:17:a5:36:cf:ae txqueuelen 1000 (Ethernet)
RX packets 2616305 bytes 221079995 (210.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2484697 bytes 3410215862 (3.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 4407 bytes 1266168 (1.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4407 bytes 1266168 (1.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
server: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255
ether 3a:64:d7:9b:80:77 txqueuelen 1000 (Ethernet)
RX packets 1 bytes 54 (54.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
server_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether d2:ed:a1:21:f0:24 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 54 (54.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@chimaera:/etc/dhcp# dhclient -v client3
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/client3/76:5a:e7:30:2e:51
Sending on LPF/client3/76:5a:e7:30:2e:51
Sending on Socket/fallback
DHCPDISCOVER on client3 to 255.255.255.255 port 67 interval 5
DHCPOFFER of 192.168.10.13 from 192.168.10.1
DHCPREQUEST for 192.168.10.13 on client3 to 255.255.255.255 port 67
DHCPACK of 192.168.10.13 from 192.168.10.1
bound to 192.168.10.13 -- renewal in 271 seconds.
root@chimaera:/etc/dhcp# dhclient -v client2
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/client2/f6:f7:dc:4d:38:36
Sending on LPF/client2/f6:f7:dc:4d:38:36
Sending on Socket/fallback
DHCPDISCOVER on client2 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 192.168.10.12 from 192.168.10.1
DHCPREQUEST for 192.168.10.12 on client2 to 255.255.255.255 port 67
DHCPACK of 192.168.10.12 from 192.168.10.1
bound to 192.168.10.12 -- renewal in 270 seconds.
root@chimaera:/etc/dhcp# dhclient -v client1
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/client1/a2:28:6b:ef:fc:90
Sending on LPF/client1/a2:28:6b:ef:fc:90
Sending on Socket/fallback
DHCPDISCOVER on client1 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on client1 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 192.168.10.14 from 192.168.10.1
DHCPREQUEST for 192.168.10.14 on client1 to 255.255.255.255 port 67
DHCPACK of 192.168.10.14 from 192.168.10.1
bound to 192.168.10.14 -- renewal in 234 seconds.
Т.е. получается, что dhclient работает. Он ведь шлет запрос именно с указанного интерфейса?
Но пинги почему-то не идут ни между client, ни server.
root@chimaera:/etc/dhcp# ping -w 3 -4 -I client1 192.168.10.1
PING 192.168.10.1 (192.168.10.1) from 192.168.10.14 client1: 56(84) bytes of data.
--- 192.168.10.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms
root@chimaera:/etc/dhcp# ping -w 3 -4 -I client1 192.168.10.13
PING 192.168.10.13 (192.168.10.13) from 192.168.10.14 client1: 56(84) bytes of data.
--- 192.168.10.13 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2056ms
Почему бы не попытаться делать Embox или его форк на базе безопасного микроядра типа seL4 + возможно на части Genode?
https://www.opennet.ru/opennews/art.shtml?num=40297
В seL4 ведь всего 10 тысяч строк сорцов, вероятно их не так сложно изучить и сертифицировать на безопасность (если это будет нужно) по сравнению с другими ядрами?
Embox — открытая ОС на «Эльбрусе»
Кстати, почему обсуждение в этой теме открыто не для всех ? :(
Genode + ядро seL4 + конфиг для кастом сборки + гипервизор или хотя бы софтовый эмулятор QEMU или паравиртуализированный XEN в софт режиме (как было в его самых первых версиях).
Лучше бы вообще Firecracker, и добавить бы ему фичу софтового эмулятора.
А в гостевой запускать Unikernel желательно на базе OpenBSD (вроде бы пока такое даже не существует?) или хотя бы обезжиренного Linux с GrSec и защищенного по инструкциям:
https://madaidans-insecurities.github.io/guides/linux-hardening.html
https://www.whonix.org/#features
https://github.com/anthraxx/linux-hardened
Т.е. все бы это целиком собиралось как некий целостный readonly LiveCD для x86 или сразу же готовый образ для dd записи на microSD соответствующего одноплатника, способный что-то писать на внешний носитель или по NFS/SSHFS и т.п.
И запускалось бы на ARMv7 Cortex A7, например, AllWinner A20 типа третьего кубитрака.
Для надежных секурных шлюзов с SSH, почтой, чатом и т.п.
CI/CD скрипты для кастомизации конфига, указания нужных для включения в сборку прикладных пакетов из обычного репозитария, шаблоны конфигов прикладнухи, и полностью автоматическая сборка в облаке on demand или сервисах типа CircleCI.
Как вам идея?
Пожалуйста, посоветуйте самые быстрые софтовые эмуляторы любых архитектур, на которых работают гостевые OpenBSD и Linux.
В качестве хостов интересны x86 (в т.ч. amd64) и ARM 32bit.
Судя по описанию:
https://sel4.systems/About/seL4-whitepaper.pdf
и более свежему материалу:
https://www.trustworthy.systems/projects/TS/makatea_reqts.pdf
Ядро seL4 предполагает возможность создания на его базе гипервизора.
Вопрос: Есть ли какие-то готовые тулзы и маны для удобного запуска в таком гипервизоре Linux и по возможности OpenBSD?
Интересует именно верифицируемый вариант seL4, а не гипервизор OKL4 из соседнего форка ядер L4.
А еще лучше, если не гипервизор, а софтовый эмулятор, IMHO он хоть и медленнее, но безопаснее гипервизора, особенно на X86.
Получается, SSH v2 (например в OpenSSH v9.0) и TLS v1.3, если не ошибаюсь ?
Чем они отличаются с точки зрения безопасности с учетом того, что оба поддерживают аутентификацию клиентов и серверов по сертификатам закрытых ключей, вероятно можно привязать аппаратный крипто и к TLS с обоих сторон также как к SSH?
Интересна их сопротивляемость к MITM и другим атакам при использовании аппаратных криптоключей на обоих концах линии.
| ← назад | следующие → |