Комиссия даже не беда, как понять что из данных на странице счета это реквизиты SWIFT?
Прикрепил файл.
Выписываете инвойс и жмете на метод оплаты "Pay by bank transfer".
Из всего что есть на скриншоте нам нужны:
1. Account Name - это мы вставляем в поле "Название организации": "OVH Hosting Limited 2"
2. BIC/IBAN - тут думаю все понятно: https://imgur.com/EtXGHQQ.png
3. Указываем комментарий и назначение платежа: https://imgur.com/YSMNoBe.png
Sort code и account number не используются при вводе.
Тинькофф также просит с определенной суммы подтвердить наличие инвойса (прикрепите pdf инвойса и отдельно скриншот с реквизитами, которые вам дали для оплаты).
Это что касается OVH и SoYouStart. На kimsufi вроде даже нет пункта оплатить by bank transfer, это уже уточнять у ТП kimsufi.
Платить лучше как минимум за месяц до конца действия услуги, начиная с рабочего дня банка (лучше в понедельник), срок действия инвойса - 15 дней. Если после окончания срока он станет в статус Expired, это не страшно. Запросите у тинькова SWIFT-лист (присылают на следующий день обычно). Если в SWIFT-листе в конце "Credited", значит перевод дошел, но еще не зачислен в OVH. В тикете к OVH присылаете чек и SWIFT-лист, ваш перевод после этого точно найдут.
bankoff хорошо проходили, но bankoff уже всё.
Пользуйтесь SWIFT'ом (+15 евро комиссии), идет долго, где тормозят его неясно, но доходит по крайней мере от Тинька в Ирландский банк.
У Тинька сейчас банк-корреспондент райфайзен, перевод, судя по комментариям на vc, может крутиться там несколько дней.
Насколько мне известно, у beget из панели создаются архивы с сохранением прав.
То есть, если на другом хостинге распакуют такой архив, то там тоже будет 700. При переезде клиенты с этим сталкиваются и, как правило, это вызывает только одну проблему: nginx не может достучаться до статики напрямую.
На скриншотах видна ситуация, что права не то чтоб были сохранены, а были изменены в процессе архивации.
На бегете с такими правами ВРОДЕ все нормально будет работать. Статика там отдается иначе, а PHP-скриптам обычно достаточно прав на чтение 0400, потому что сами файлы исполняются бинарником на стороне.
Когда вы находитесь в Rescue, вы находитесь в другой системе. Вы можете примонтировать разделы командой mount и посмотреть логи, проверить диски утилитой smartctl, fsck для проверки ФС и так далее.
Может просто файловая система полетела или диск крякнул, а вы хотите все переустанавливать, такое себе решение.
Самое интересное, что у сайта нет такого поддомена. Это так перенеслась запись.В оригинале она значится какMX - fingeniy.com - 10 mailЧто сделать, удалить эту строку вообще?
Я делал выводы на основе вашего скриншота. Прикрепил.
1. Есть запись типа "A", с названием mail, включено проксирование CF.
2. Есть запись типа "MX", указывающая на mail.fingeniy.com. (то что в оригинале вы видите иначе - это просто из-за разных панелей, обозначает это тоже самое).
3. CF на скриншоте предупреждает, что для записи типа "A" включено проксирование и почта ходить в сторону домена не будет.
Если у вас отсутствует MX-запись или она некорректна, то удаленный почтовый сервер не поймет куда доставлять вам почту. MX служит не для отправки почты, а для принятия. Оставьте все как на этом скриншоте, единственное что нужно убрать проксирование для записи, которая выделена мной красным цветом.
Упс, заработал!И вот еще не знаю, как правильно прописать эту строку
В панели она числится: 10 mail (вместо mail.fingeniy.com), а в cloudflare еще нужно выбрать Priority (required) от 0 до 65535 - как это правильно прописать, чтобы было без ошибки?
Необходимо отключать проксирование для поддомена, который использует MX-запись.
В вашем случае это поддомен "mail" с флагом Proxied.
Чтобы не платить 5 тысяч рублей в год за скрипт, который блокирует на уровне PHP 😀
Хотя, этому форуму не помешал бы такой скрипт...
Почему blackhole лучше/экологичнее?
Меньше накладных ресурсов, маршрут отправляется в нулл на 3 уровне модели OSI (считайте это уровнем IP-адреса).
Формально, iptables тоже так умеет, если это raw и если это PREROUTING, однако, он работает с netfilter, что по моему мнению может добавить накладные ресурсы, но не факт.
В iptables вы дропаете пакет на 4 уровне - это уже когда идет разбор tcp/udp-пакета, адреса назначения, протокола и прочего, что в данной ситуации нам совершенно не нужно.
iptables хорош, если вам нужно не только заблокировать, но и посчитать количество пакетов, зажурналировать их.
ip route add blackhole ip/netmask
Экологически чистое зануление маршрута. 😀
Думаю, поможет до тех пор, пока промежуточный узел не додумается вырезать/модифицировать этот заголовок. А как мы помним, трафик без шифрования может быть модифицирован полностью, вплоть до того что клиенту придет HTTP-заголовок редиректа на плохой сайт вместо оригинального контента, который отдает сервер. Конечно, такая наглость еще не встречалась в моей практике, но тут сам факт что такое возможно.
Еще раз, в рунете не будет проблем с SSL, так как если скурвится LE то пропадут сертификаты почти у всех, и просто изменится общий фон.
Для критичных ресурсов будем использовать самоподписанные сертификаты и отправлять клиентам файлы сертификата собственного мини-УЦ, чтобы они добавили их в браузер (такая политика спасет от атаки посередине), из минусов - напрягать клиентов. Для некритичных голый HTTP. 😀
