landergate

Все блоки адресов регистрируются у RIPE/ARIN и привязаны к организациям.
Youtube может видеть, что эти блоки адресов выделены коммерческой компании, сдающей ресурсы в аренду, что, при совпадении других факторов (высокая частота, схожесть), может указывать на аномальный характер голосов и предположить накрутку.

Потому, что для возможности маршрутизировать ваш трафик через VPN, ваша таблица маршрутизации вынуждена исключать адрес самого VPN-шлюза, иначе она не сможет соединиться с VPN-шлюзом.

Если вам необходимо сокрытие адреса и на этом сервере, этого можно добиться подключением с другого места, т.е. либо перенеся VPN-сервер на другую ноду, либо используя сторонние прокси, либо используя Tor.

Ещё можно подключаться к серверу по SSH по его внутреннему IP в этой приватной сети, а затем входить на сайт через local port forwarding, настроив его, например, на 1234:127.0.0.1:80, а затем открывая у себя в браузере 127.0.0.1:1234. В этом случае в логах сайта подключения будут происходить с 127.0.0.1.
Возможные нюансы: 1) ссылки на сайте должны быть относительными, а не заполнены полным доменным именем, иначе в браузере они все будут выглядеть не как 127.0.0.1:1234/something/, а всё-время переключать на основной домен; 2) сам сайт для этого должен разрешать приём подключений без указания домена, иначе случится несовпадение location/vhost и сайт таким способом не откроется.

Передавать их не обязательно.
В чеке заинтересован сам покупатель для решения гражданских споров.

Для ФНС важна декларация факта дохода.

Если речь о hidden-сервисе, то хостер не видит ничего, кроме множества разных открытых зашифрованных TLS-соединений, которые не может идентифицировать или связать непосредственно с тором. Внешне, это постоянно сменяющиеся коннекты с разным объёмом трафика от разных адресов (внутренних мостов), через которые пользователи посещают сайт.

В трафике к hidden-сервисам, tor exit ноды не участвуют. Все соединения остаются в пределах сети тор.

Единственное, что может видеть хостер, это сам факт первичного подключения сервера к тору, т.к. клиенты тор совершают хэндшейк по общему паттерну. Этого можно избежать при использовании pluggable transports и обфускации, но в этом случае хостер будет видеть постоянный нестандартный трафик, хотя сам по себе этот факт обычно не нарушает ничей ToS.

В теории, в серьёзных расследованиях место размещения может быть выявлено через косвенную информацию: сотрудничество с хостерами, общесетевой DPI на территории размещения, косвенные данные о трафике, человеческие ошибки операторов ресурса.

Можно хранить массив в типе колонки JSON (доступно с MySQL 5.7 / MariaDB 10.2.3).
Можно хранить массив бинарно в типе BLOB, десериализуя данные в приложении.

Guacamole
https://guacamole.apache.org/
Более активно развивается, разворачивается на Linux или Docker.
Документация: https://guacamole.apache.org/doc/gug/

Myrtille
https://cedrozor.github.io/myrtille/
Сейчас мало развивается, разворачивается на Windows и IIS.
Документация: https://github.com/cedrozor/myrtille/blob/master/D...

Оба являются веб-шлюзом для RDP и SSH. Не важно, на какой платформе он будет развёрнут, пользователи смогут подключаться через него к RDP-серверам, используя только браузер.

Миллионы записей - это совершенно обычный и, я бы сказал, крайне небольшой кейс для MySQL.

Самое быстрое: отпрофилировать запросы (например, performance_schema=1 и подключить sys-таблицы, они наполнятся данными по прошествии времени), найти неоптимизированные индексами и добавить недостающие индексы на этих таблицах.

У soyoustart есть перенос на новый сервер с сохранением ip?

Только Failover-адресов:



Основной (не-failover) адрес перенести самостоятельно не получится. Можно просить такую возможность тикетом в саппорт, если они смогут перероутить его вручную.

Есть ли фича, переноса данных, образ залить на новый сервер?

Нет, но перенести данные можно и самостоятельно, загрузив второй сервер с rescue-образа, примаунтив диск и rsync'нув на него данные с первого сервера:

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} root@firstserver:/ /mnt/mounted_hdd

Pillars - это лист переменных/данных, таргетируемый на конкретные миньоны. Они позволяют, например, переиспользовать одну и ту же формулу/стэйтфайл, заполняя через pillars на разные миньоны разные переменные. В каком-то смысле, это аналог Grains, но Grains генерирует и хранит у себя сам миньон, в то время, как Pillars передаются от мастера на миньон в момент рендеринга стейта на мастере, что делает его безопасным транспортом для чувствительных данных, например паролей, т.к. другие миньоны не смогут их получить от мастера, если они не являются таргетом этих пилларов.

Mine - это способ автоматически собирать определённые данные с миньонов и шарить их всем остальным миньонам, дёргая какие-нибудь сценарии при изменении этих данных. Позволяет, например, получить приватные IP-адреса всех известных бэкендов нашего приложения и автоматически обновить их список на HAProxy.

Хочу таким образом уменьшить количество запросов на сервер

Это не уменьшит количество клиентских запросов на веб-сервер. Запросов останется такое же количество, просто источником данных для выдачи станет не диск, а СУБД.
В большинстве случаев, обращение к диску дешевле, чем обращение к СУБД.

Для уменьшения количества клиентских запросов на веб-сервер, можно:

• Перенести изображения на внешний CDN/облачное хранилище: Amazon S3 или Openstack Swift у большинства облачных провайдеров.
  
• Перенести изображения на ещё один веб-хостинг, используя его исключительно для публикации изображений.
  

Подключиться к ноде для управления кошельком можно через bitcoin-cli:

bitcoin-cli -rpcconnect=1.2.3.4 -rpcuser=someuser -rpcpassword=somepassword

Со стороны ноды, к которой вы подключаетесь, параметры rpcuser/rpcpassword должны быть заранее объявлены в bitcoin.conf. Применение конфига требует перезапуска ноды.

Имейте ввиду, что:

• Подключение к ноде Bitcoin по умолчанию разрешено только с 127.0.0.1. Если вы находитесь вне сервера, объявите разрешённые IP для подключения к ноде через параметр `rpcallowip` в bitcoin.conf (поддерживается формат 1.2.3.4/24, он же CIDR), а также в довесок настройте поверх firewall, чтобы превентивно исключить незапланированные подключения к ноде, ограничив их по IP. Публиковать ноду наружу без этих мер - значит создавать риск, что к ноде смогут подключаться посторонние люди.
  
• Подключение по RPC происходит открытым текстом. Соседи по сети, ваш провайдер и государство могут перехватить данные, поскольку они передаются в открытом виде. Затем они могут использовать эти параметры для подключения к вашей ноде. Если вы не используете между клиентом и нодой никакого защищённого туннелирования, стоит хотя бы подключаться к ней через SSH port forwarding, пряча тем самым трафик от посторонних глаз.
  

Вообще, у вопроса нет никакого контекста. Неизвестно, для чего вы это делаете - домашнее использование или интеграция между серверами. Если вы пользуетесь этой схемой для подключения извне, и если сервер нода размещена на линуксе, есть смысл подключаться сразу по SSH и выполнять команды через bitcoin-cli терминально, из под того же пользователя, из под которого запущен bitcoind.

Опрашивать файл не надо, достаточно использовать inotify от самой ОС.
Под Python есть кросс-платформенные реализации отслеживания изменения файлов через inotify-like подсистемы. Отслеживающие скрипты будут ловить событие по итогам записи и закрытия файла, даже без коммуникации с основным процессом.

А так, скрипты могут взаимодействовать друг с другом как по HTTP (публикуя от себя маленький веб-сервер), так и по любому самописному RPC-протоколу поверх TCP или unix socket'ов.

Если проект некоммерческий, но является решением какой-то задачи, наиболее эффективно будет показать это решение на профильных форумах/сообществах тех специализаций, где часто сталкиваются с задачами, которые покрывает это ПО.

У любой профессии или специализации в сети, как правило, уже есть наиболее крупные сообщества, форумы, чаты, причём многие из них существуют в отрыве от социальных сетей, как самодостаточные сайты, где специалисты ежедневно проявляют активность. Такие сообщества собираются ещё с нулевых, и имеют много активных мемберов, которые не оставят ваш проект без внимания, если он им действительно полезен.

Важный нюанс: чтобы продукт получил обратную связь, нужно понимать, что долгие подготовительные сборки и отсутствие простых гайдов по запуску могут оттолкнуть неподготовленных пользователей, если у них нет опыта сборки подобных проектов. Упростив этот этап, вы увеличите потенциальную аудиторию и вероятность того, что страницу не закроют с мыслью "чёт сложно" ещё даже не начав.

Сотни:
https://github.com/goq/telegram-list
https://github.com/A-gambit/awesome-telegram-chats