Author: admin

Что делать, если …

admin

… что-то упало (как телеграм) или недоступно?

Во-первых, надо заранее подготовиться и заиметь сервера где-то там далеко.
Во-вторых, надо сказать секретную команду

ssh -D 8123 -f -C -q -N user@server

Она поднимет socks5 прокси на localhost:8123

И наконец, указать в вашем любимом браузере, телеграмчике и остальном sock5 прокси.

Проверить работоспособность прокси можно командой

httping -x localhost:8123 -5 -g http://google.com
PING google.com:80 (/):
connected to google.com:80 (325 bytes), seq=0 time=636.58 ms 
connected to google.com:80 (325 bytes), seq=1 time=506.72 ms 
connected to google.com:80 (325 bytes), seq=2 time=657.07 ms

Ученье свет, а неученых тьма

admin

Внезапно и совершенно неожиданно для себя обнаружил, что на udemy курсы значительно внятней и понятней, чем на coursera. Мой любимый тест “на кубернетес”, который coursera вместе с Хайтауэром провалила тотально и полностью (там большая часть курса – тотальный бред. С тех пор я уверен, что в Kubernetes Up & Running Хайтауэр только ради политкорректности), тут не вызвал никаких проблем.

В общем, я на udemy набрал курсов, теперь во всю обучаюсь.

Картинка просто для привлечения внимания и как свидетельство, что я там слушаю.

Новый датацентр. Сертификаты в почту

admin

Для своих нужд я обычно ставлю Zimbra Open Source Edition. Простой, дуракоустойчивый почтовый сервер со всякими необходимыми плюшками. Но есть в нем одна маленькая проблема: по умолчанию он генерит самоподписанные сертификаты, на которые ругаются всякие почтовые клиенты. Значит, надо подсунуть сертификаты от letsencrypt

Сделаем на сервере каталог для сертификатов

mkdir -p /opt/zimbra/ssl/letsencrypt/
chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/

Опять же, маленький скриптик, который пускается руками после обновления сертификатов и проверки готовности всего ко всему. Он же zimbra_check

cat /opt/www/chain.pem >> /etc/letsencrypt/live/mail.ka12.co/fullchain.pem 
scp  /etc/letsencrypt/live/mail.ka12.co/* root@mail:/opt/zimbra/ssl/letsencrypt/
ssh root@mail "chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"

Логика понятна из текста: добавляем CA ключ (отсюда) в цепочку, копируем все это в потроха зимбры и проверяем, согласится ли она это съесть. Обычно ответ “да”, но иногда она взбрыкивает и надо смотреть, чего же ей не нравится. Если ошибок нет, то можно запустить zimbra_deploy

#!/bin/bash
ssh root@mail "runuser -l zimbra -c 'zmcontrol stop'"
ssh root@mail "cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.`date \"+%Y%m%d\"`"
ssh root@mail "runuser -u zimbra cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"
ssh root@mail "runuser -l zimbra -c '/opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem'"
ssh root@mail "runuser -l zimbra -c 'zmcontrol start'"

Он тормозит нафиг всю зимбру, бекапит и деплоит сертификаты и снова запускает все назад.

Новый датацентр. Web

admin

Что самое главное во всем этом? Правильно, наши интернетики с кисками и прочим. А значит, надо обеспечить заход снаружи внутрь по https

На данный момент я знаю всего 3 способа: с помощью nginx, apache и traefik. Apache как-то старо, traefik наоборот, слишком новомодно.

Предупреждаю сразу: использовать в докере nginx c nginx-gen и companion, как описано вот тут https://github.com/gilyes/docker-nginx-letsencrypt-sample – нельзя. Проблема простая: генератор тупо мешает ip бэкэндов как ему понравится.

Краткий план: ставим виртуалку

virt-builder centos-7.4 --arch amd64 -o nginx.ka12.co.img --size 20G --format qcow2 --hostname nginx.ka12.co --ssh-inject root:file:/root/multik.sshkey --root-password file:root_pass --copy-in ifcfg-eth0:/etc/sysconfig/network-scripts/ --copy-in resolv.conf:/etc
virt-install --name nginx.ka12.co --network bridge=virbr100 --memory 2048 --disk path=nginx.ka12.co.img --import --os-variant centos7.0 --graphics vnc,listen=172.16.100.1 --noautoconsole

бутстрапим ее

ansible-playbook -i inventory -l nginx* centos-bootstrap.yml

Добавляем в нее нужное

yum -y install freeipa-client && ipa-client-install --mkhomedir
yum install certbot python2-certbot-nginx nginx

И запускаем nginx

openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
systemctl start nginx

Берем из git (https://github.com/kiltum/newdc/tree/master/nginx) и кладем в /opt/www

Там два темплейта – первый для просто “сделай так, что бы nginx узнал о сайте”, а второй – уже готовый полноценный конфиг.

Ну а что делает скрипт new_site, думаю разберетесь сами. Только email правильный пропишите.

Запускаем ./new_site mail.ka12.co и вот результат:

После меняем конфиг сайта как нам надо и вуаля! Теперь по приходу емайла от letsencrypt заходим и обновляем все сразу.

Новый датацентр. Докер

admin

Следующим большим шагом в постройке “датацентра” у меня будет разворачивание докера. Без него нынче никуда, да и удобный он, зараза.

Согласно всем мануалам для новичков, для минимально живучего кластера необходимо заиметь три машины. А у меня одна, но зато физическая. Значит, поднимаю три виртуалки и туда запихиваю докер.

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

Добываю/делаю правильный ifcfg фаил

cat ifcfg-eth0
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="172.16.100.11"
PREFIX="24"
GATEWAY="172.16.100.1"
NM_CONTROLLED="no"

Добавляю пароль рута в файл root_pass и кладу рядом свой публичный ключ. Рядом же resolv.conf. Затем создаю образ диска

virt-builder centos-7.4 --arch amd64 -o docker1.ka12.co.img --size 80G --format qcow2 --hostname docker1.ka12.co --ssh-inject root:file:/root/multik.sshkey --root-password file:root_pass --copy-in ifcfg-eth0:/etc/sysconfig/network-scripts/ --copy-in resolv.conf:/etc

И запускаю машину с ним.

virt-install --name docker1.ka12.co --network bridge=virbr100 --memory 8096 --disk path=docker1.ka12.co.img --import --os-variant centos7.0 --graphics vnc,listen=172.16.100.1 --noautoconsole

Минута и виртуалка готова. Меняем ip адрес в конфиге+хостнейм и повторяем так еще два раза. Все, ноды для кластера готовы.

Добавляем их в инвентори и бутсрапим до приемлемого состояния.

ansible-playbook -i inventory -l docker* centos-bootstrap.yml

Делать еще один плейбук лень, поэтому просто прохожу по хостам с командой

yum -y install freeipa-client && ipa-client-install --mkhomedir

ansible-playbook -i inventory docker-install.yml

И на любой машине проверяю, что докер докерит

docker run hello-world

Так как у нас инфраструктура пока из одного хоста, заморачиваться распределенным хранилищем нет смысла от слова совсем. Поэтому просто раскидаю по хостам nfs

На хосте:

mkdir -p /opt/nfs
chmod 777 /opt/nfs
cat /etc/exports
/opt/nfs 172.16.0.0/16(rw,sync,no_root_squash,no_all_squash)
systemctl restart nfs-server

Проверяю, что увидит докер

# showmount -e 172.16.100.1
Export list for 172.16.100.1:
/opt/nfs 172.16.0.0/16

Создаю супер-каталог для volume

mkdir -p /opt/nfs/data
chmod 777 /opt/nfs/data

Теперь на докер-хосте создаю volume


docker volume create --driver local --opt type=nfs --opt o=addr=172.16.100.1,rw --opt device=:/opt/nfs/data --name data

И проверяю

[root@docker1 ~]# docker volume ls
DRIVER VOLUME NAME
local data
[root@docker1 ~]# docker volume inspect data
[
{
"CreatedAt": "2018-01-27T08:46:56-05:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/data/_data",
"Name": "data",
"Options": {
"device": ":/opt/nfs/data",
"o": "addr=172.16.100.1,rw",
"type": "nfs"
},
"Scope": "local"
}
]

Теперь проверяю, как с этим будут работать контейнеры

docker container run -ti -v data:/data alpine sh

Там в /data можно посоздавать файлики и вообще поиграться “как будто в реальной жизни”.

Новый датацентр. Сервер.

admin

Долго ли, коротко, но дошел я до того, что мне стало уж очень дорого пользоваться услугами Amazon. Оно удобно, но дорого. Значит, мне опять дорога назад, к выделенному серверу.

Но терять кучку удобных штук типа докера нет желания, поэтому буду строить сразу и с запасом. Итак, что мне охота

1. Централизованное управление аккаунтами. Для всяких ssh, git и прочим
2. KVM и докер.
3. Чистый, не засранный хост. Не хочу видеть по интерфейсу и 10 правил на каждый контейнер.
4. Разное.

Итак, стадия номер 1 или “подготовка”. Все использованное мной можно найти тут: https://github.com/kiltum/newdc Ну и я подозреваю, что вы уже имеете опыт администрирования linux, поэтому буду только намечать путь.

Арендую новый сервер. Hetzner, leaseweb – их много. И ставлю туда пустую и голую CentOS 7. Никаких панелей, рюшечек и прочего. Из моих уже личных требований – поставить все на raid1.

Бутстраплю ее с помощью ansible и роли centos-bootstrap.yml. Там снос selinux, firewalld, установка ntp и прочих пакетиков и обновление системы. Самый необходимый минимум.

Ставлю KVM. Эта операция одноразовая, поэтому можно и руками.

yum install qemu-kvm libvirt libvirt-python libguestfs-tools virt-install

Сношу дефаултную сеть от KVM. Это автоматически избавляет меня от кучки правил в iptables.

virsh net-autostart --disable default
virsh net-destroy default

Создаю тупой интерфейс, куда буду цеплять с помощью бриджа виртуалки

modprobe dummy numdummies=1
echo "dummy" > /etc/modules-load.d/dummy.conf
echo "options dummy numdummies=1" >> /etc/modprobe.d/dummy.conf

Генерирую для него мак-адресс (в принципе можно от балды, но лучше что бы с первыми октетами от KVM – так симпатичней)

hexdump -vn3 -e '/3 "52:54:00"' -e '/1 ":%02x"' -e '"\n"' /dev/urandom

И делаю конфиг-фаил для этого интерфейса

cat > /etc/sysconfig/network-scripts/ifcfg-dummy0
DEVICE=dummy0
MACADDR=52:54:00:1b:e1:80
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
IPV6INIT=no
BRIDGE=virbr100

и описываю бридж

cat > /etc/sysconfig/network-scripts/ifcfg-virbr100
DEVICE=virbr100
NAME=virbr100
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
DELAY=2
STP=on
IPADDR=172.16.100.1
NETMASK=255.255.255.0
IPV6INIT=no

Поднимаю созданное

ifup virbr100

В результате я получил следующее

2: dummy0: mtu 1500 qdisc noqueue master virbr100 state UNKNOWN qlen 1000
link/ether 52:54:00:1b:e1:80 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe1b:e180/64 scope link
valid_lft forever preferred_lft forever
...
5: virbr100: mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 52:54:00:1b:e1:80 brd ff:ff:ff:ff:ff:ff
inet 172.16.100.1/24 brd 172.16.100.255 scope global virbr100
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe1b:e180/64 scope link
valid_lft forever preferred_lft forever

Разрешаю форвардинг пакетиков между интерфейсами

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" >> /etc/sysctl.conf
sysctl -p

Для полноценной работы виртуалок я добавляю в стандартный набор правил еще одно, которое обеспечивает виртуалкам выход в интернет. Вместо иксиков подставьте свой внешний ipшник

-A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x

И в принципе все, я готов создать первую виртуалку.

virt-install --name head.ka12.ko --network bridge=virbr100 --memory 1024 --disk path=head.ka12.co.img,size=30 --cdrom ../iso/CentOS-7-x86_64-Minimal-1708.iso --graphics vnc,listen=172.16.100.1 --noautoconsole

И получаю к ней доступ по VNC

virsh vncdisplay head.ka12.co

Так как пока нету ничего даже похожего на нормальный доступ, пробрасываю VNC порт на локальную машину

ssh -L 5901:172.16.100.1:5900 kiltum@ka12.co

Дальше открываю VNC клиент и по адресу localhost:5901 получаю консоль виртуалки. Дальше как обычно “Далее-далее-подождать и перезагрузить”. Опять же можно было заморочиться и использовать автостарты, но мне лень такое делать на редких и одноразовых операциях.

У этой новой виртуалки будет совершенно ожидаемый адрес 172.16.100.2. После “ребута” инсталлятора снова запускаем и ставим в автозапуск

virsh start head.ka12.co
virsh autostart head.ka12.co

Первым делом надо решить вопрос с доступом в мою “инфраструктуру”. Тут пока ничего лучше не придумали, как openvpn. Запихиваю в /etc/resolv.conf временный адрес DNS сервера и начинаю

yum -y install epel-release mc
yum -y install openvpn easy-rsa

Меняю конфиги openvpn

cat server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 172.16.101.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 172.16.0.0 255.255.0.0"
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 172.16.100.2"
;push "dhcp-option DOMAIN ka12.co"
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
verb 3

Обратите внимание, специально закомментировал некоторые строки, которые понадобятся в будущем. Теперь генерирую ключи

mkdir -p /etc/openvpn/easy-rsa/keys
cp -rf /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa
mcedit /etc/openvpn/easy-rsa/vars
cp /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf
cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
cd /etc/openvpn/easy-rsa/keys
cp dh2048.pem ca.crt server.crt server.key /etc/openvpn
cd /etc/openvpn/easy-rsa
./build-key client

Разрешаю форвардинг

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" >> /etc/sysctl.conf
sysctl -p

и запускаю openvpn

systemctl enable openvpn@server.service
systemctl start openvpn@server.service

так как там все по умолчанию, очищаю правила фаерволла на виртуалке

iptables -F

Все, теперь на хосте надо открыть порт 1194/udp и пробросить его на виртуалку

-A PREROUTING -d x.x.x.x/32 -i eth0 -p udp --dport 1194 -j DNAT --to-destination 172.16.100.2
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT

Добавляю роутинг до подсети vpn

ip route add 172.16.101.0/24 via 172.16.100.2

cat > /etc/sysconfig/network-scripts/route-virbr100
172.16.101.0/24 via 172.16.100.2 dev virbr100

Делаю темплейт клиентского конфига

cat client.template
client
dev tun
proto udp
remote vpn.ka12.co 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
key-direction 1
remote-cert-tls server
mssfix
<ca>
ca.crt
</ca>
<cert>
client.crt
</cert>
<key>
client.key
</key>
<tls-auth>
ta.key
</tls-auth>

И заполняю его (в дальнейшем я сделал маленький скрипт gen_config.sh)

sed -e '/ca.crt/rca.crt' -e '/client.crt/reasy-rsa/keys/client.crt' -e '/client.key/reasy-rsa/keys/client.key' -e '/ta.key/rta.key' -e '/crt/d' -e '/\.key/d' client.template | sed -e 's/#.*$//' -e '/^$/d' > cl.ovpn

Цепляюсь и проверяю доступность хоста через vpn

traceroute 172.16.100.1
traceroute to 172.16.100.1 (172.16.100.1), 64 hops max, 52 byte packets
1 172.16.101.1 (172.16.101.1) 53.941 ms 48.797 ms 47.938 ms
2 172.16.100.1 (172.16.100.1) 49.186 ms !Z 48.813 ms !Z 49.865 ms !Z

Пробрасываю ключ, бутстраплю виртуалку и ставлю в ней FreeIPA
ssh-copy-id root@172.16.100.2

ansible-playbook -i inventory -l head.ka12.co centos-bootstrap.yml

yum -y install ipa-server bind bind-dyndb-ldap ipa-server-dns

ipa-server-install --setup-dns --mkhomedir --allow-zone-overlap

Меняю шелл по умолчанию

kinit admin
ipa config-mod --defaultshell=/bin/bash

Внезапно оказалось, что FreeIPA с 1 гигом памяти стартует очень тяжко. Добавляю памяти

virsh setmaxmem head.ka12.co 4G --config
virsh setmem head.ka12.co 2G --config

И включаю VPN на полную

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 172.16.100.2"
push "dhcp-option DOMAIN ka12.co"

Добавляю pam сервис

cd /etc/pam.d/
ln -s system-auth openvpn

Добавляю группу openvpn и sshd и заношу в нее меня. В принципе все тоже самое можно сделать через веб-интерфес FreeIPA.

ipa hbacsvc-add openvpn
ipa hbacrule-add allow_openvpn
ipa hbacrule-add-service allow_openvpn --hbacsvcs=openvpn
ipa hbacrule-add-user allow_openvpn --user=kiltum
ipa hbacrule-add-service allow_sshd --hbacsvcs=sshd
ipa hbacrule-add-user allow_sshd --user=kiltum
ipa hbacrule-add-host allow_sshd --hosts=head.ka12.co
ipa hbactest --user=kiltum --host=head.ka12.co --service=sshd

Теперь остался последний шаг. Добавляю в конфиг сервера

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

а в конфиг клиента

auth-user-pass

И всё.

В случае проблем проверить работу авторизации можно и прямо на стороне сервера:

pamtester openvpn kiltum authenticate

Что же получил на данном этапе?

1. Хост, на котором крутится только KVM и больше ничего. А значит: ошибиться негде, ломать тоже особо нечего.
2. OpenVPN, доступ до которого защищен сразу двумя методами: клиентским сертификатом и логином-паролем.
3. Внутренний DNS, который снаружи никак не виден.
4. Управление пользователями/группами/сервисами. Располагается исключительно во внутренней сети.
5. Даже если опустить везде фаирволлы, то ничего нового не будет доступно снаружи.

Postgres PITR to one file

admin

У штуки под названием postgres есть очень хороший способ бекапа. Называется он PITR. Стандартный процесс бэкапа выглядит так:

touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/

В чем засада? Засада в tar. В данном случае он тупо копирует весь каталог postgres со всеми потрохами. А это дает дикую нагрузку на диск, что в реальной жизни огорчает postgres до изумления. Конечно если есть возможность, то лучше создавать такой tar где-нибудь на другом диске или даже сервере, а если нет? И нет возможности поднять где-нибудь slave сервер и делать бекапы с него?

Первым предположением будет добавить ключик z или j – пусть сразу пакует. И тут сразу же возникает проблема: нельзя добавить файликов в уже запакованный tar. Надо распаковывать, добавлять и снова запаковывать. Какие есть пути решения?

1. Так и таскать два .tar.gz файла. Одиним меньше, другим больше …
2. Забить и переложить проблему на админов сторов. Пусть дают больше места и скорости.
3. Сделать скрипт, который где-то там, далеко, будет перепаковывать файлы. Заодно и целостность бекапа проверит.

Но я решил пойти другим путем. Он чуть-чуть посложнее, но зато результатом становится один сжатый файл. Вот упрощенный псевдокод:

mkfifo backup_fifo
sleep 98765 > backup_fifo
stdbuf -i0 -o0 -e0 cat backup_fifo | cpio -o -H tar | pigz -q > /path/to/backup.gz
psql -c "select pg_start_backup('hot_backup');"
stdbuf -i0 -o0 -e0 find postgres/data -type f > backup_fifo
psql -c "select pg_stop_backup();"
stdbuf -i0 -o0 -e0 find postgres/archive -type f > backup_fifo
kill sleep

Расскажу последовательно:

mkfifo backup_fifo. Создаем fifo фаил. Он будет у нас очередью для имен файлов, подлежащих архивированию.

sleep 98765 > backup_fifo. Открываем fifo и держим его открытым. Думаю, что 68 суток должно хватить для любого бекапа.

cat backup_fifo | cpio -o -H tar | pigz -q Запускаем процесс “таренья” всего, чьи имена прилетят в fifo. Так как tar не умеет читать имена файлов с stdin, использовал cpio в режиме tar. Ну и pigz – это параллельный gzip.

А дальше полностью повторяем стандартный процесс бекапа postgres, без каких-либо отступлений от генеральной линии. В конце прибиваем sleep и fifo закрывается, закрывая за собой все остальное.

В чем тонкости?

1. Использование sleep в качестве держалки для fifo. Я больше не смог вспомнить ни одной утилиты, которые ничего никуда не пишут, но открывают stdout & stdin.
2. Использование stdbuf. Если её не использовать, то из-за буферизации будет невозможно понять, какой и когда закончился этап. В результате легко получается, что tar забирает не то, что нужно.

Для предотвращения гонок в пункте 2 я пробовал вставлять в бекап файлы-маркеры и потом отслеживать время доступа к ним, но решение получилось … не элегантным и потребовало третий поток для исполнения.

Понятно, что в реальном скрипте все обвешано проверками и прочими тонкостями, но суть я скопипастил точно.

ЗЫ Картинку честно стащил из интернета.

Установка High Sierra Beta с нуля

admin 
1. Надо иметь Developer Account
2. Надо иметь флешку ( я обозвал HighSierra ) - с флешки все удалится!
3. Открыть macappstores://itunes.apple.com/app/id1209167288
4. Скачать - должно получиться 5+ гигов
5. В терминале
sudo /Applications/Install\ macOS\ High\ Sierra\ Beta.app/Contents/Resources/createinstallmedia --volume /Volumes/HighSierra --applicationpath /Applications/Install\ macOS\ High\ Sierra\ Beta.app/ --nointeraction &&say Boot drive created
6. Дождаться Boot drive created и загрузиться с флешки. Дальше как обычно

STM32 ADC Multiple Channels HAL

admin

Ну или подобными вопросами заполнены тематические конференции. И большинство из них без ответов.

Суть проблемы проста: если в STM32CubeMX включить в АЦП один канал, то все работает изумительно. Примеры есть повсюду и код работает стабильно. Но если включить несколько, то все ломается. При вызове HAL_ADC_GetValue на выходе получается “мусор”, содержащий случайную выборку с каналов.

Решение: в коде HAL содержится ошибка. В функции HAL_ADC_ConfigChannel индусы заложили такую логику, которая препятствует работе более чем с одним каналом. Согласно ей, перед измерением надо каждый канал конфигурировать с Rank = ADC_RANK_NONE, а затем снова его же конфигурировать, но уже с другим rank.

Если делать по документации, то вместо конфигурирования одного канала происходит конфигурирование всех каналов.

В общем, рассказывать дольше, чем показать код

Новый сервер на CentOS 7

admin

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

После совершенно стандартных действий по обновлению, выключению ненужных сервисов и прочего встал вопрос о первоначальном тюнинге.

Первое, что необходимо сделать – отрубить 99,9% автоподбиральщиков паролей.

# cat /etc/sysconfig/iptables|grep 22
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT

Затем ставим sslh – мультиплексор протоколов. Его задача – дать доступ до основных сервисов через 443 порт.

# cat /etc/sslh.cfg
# This is a basic configuration file that should provide
# sensible values for "standard" setup.

verbose: false;
foreground: true;
inetd: false;
numeric: false;
transparent: false;
timeout: 2;
user: "sslh";
# Change hostname with your external address name.
listen:
(
{ host: "edge"; port: "443"; }
);
protocols:
(
{ name: "ssh"; service: "ssh"; host: "localhost"; port: "22"; },
{ name: "openvpn"; host: "localhost"; port: "1194"; },
# { name: "xmpp"; host: "localhost"; port: "5222"; },
{ name: "http"; host: "localhost"; port: "80"; },
{ name: "ssl"; host: "localhost"; port: "443"; log_level: 0; },
{ name: "anyprot"; host: "localhost"; port: "443"; }
);

Как видите, конфигурация 100% стандартная, за исключением того, что мне не нужен xmpp. после обкатки можно будет и закрыть “обычный” ssh порт совсем. Минусом станет то, что в логах и утилитах пользователи станут заходить через localhost. Реальные адреса будут видны только через journald

… и все. В остальном инсталляция CentOS 7 не требует дальнейших движений напильником.

Elite:Dangerous. Записки коммандера

admin

Что-то перестал я писать про одну из самых замечательных игр. Просто потому что писать особе не о чем: летаю, собираю, сбиваю и бываю сбитым. Из особых новостей: взял исследовательскую элиту. Сейчас потихоньку облетываю те корабли, которые по каким-то причинам пропустил.

В общем, ничего этакого пока не случилось, а значит и писать не о чем 🙂

Криптовалюты – чего куда зачем?

admin

Биткоин, эфир … “крипта” и какая-то “ико”. В нашей окружающей жизни стали появляться странные слова, связанные с криптовалютой. Набрав в любом поисковике bitcoin, вы 100% попадете на какой-нибудь сайт, рассказывающий о преимуществах этого средства и рисующий офигительные графики роста или падения курса. Попытка разобраться обычно приводит к заумным статьям про майнинг, хеши и прочие термины, которые ни разу не понятны …

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

Представьте себе, что вам необходимо подписать очень важный договор. Да так, что бы оспорить ваши подписи было очень тяжело. Что вы делаете? Вы идете с этим договором к нотариусу, платите немного денег и он заверяет своей подписью, что вы это вы и никто вас к этом не принуждает. Но вам настолько важен этот договор, что вы идете еще к паре-тройке нотариусов и с их помощью заверяете как свою подпись, так и подпись предыдущего нотариуса.

Теперь, что бы кому-то подделать вашу подпись, надо пройтись по всем нотариусам и заставить их переподписать “задним числом” договор. Дело это сложное и при достаточном количестве нотариусов практически не выполнимое.

А теперь представьте себе, что у вас есть какая-нибудь картинка. Скажем, сфотографированный лично вами закат. Картинка получилась настолько красивой, что её пожелал купить кто-то в интернете. Но просто переслать почтой картинку мало. Ведь только ваша совесть остановит вас от того, что бы сделать еще одну продажу. Что делать?

Умные люди придумали, как перенести механизм с нотариусами в интернет.

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

Следующий шаг был очень прост: вместо файлов использовать цифры. Которыми обозначили число хранящихся монет. Так как для расчета “подписей” используются криптоалгоритмы, то вполне логично получилось название “криптовалюта”. Так как везде используются компьютеры, то получилась адская смесь терминов, которая вводит в заблуждение обычный людей (и некоторых не обычных). Давайте я расскажу еще раз пошагово, но уже с использованием терминов, а вы сами поймаете аналогии.

1. Нам нужен “кошелек”. Кошелек – это ваш уникальный адрес в сети. Именно уникальный, второго такого в сети нет. Уникальность обеспечивается сложными, на “тыщу мульонов” раз проверенными алгоритмами.
2. Вы ставите программу, которая генерирует кошелек, соединяется с серверами которые поддерживают работу валюты и делает кучу другой работы необходимой для функционирования.
3. Затем вы кому-то даете адрес своего кошелька и просите перевести денег на него.
4. Этот кто-то отправляет в сеть команду “перевести с кошелька А на кошелек Б столько-то денег”.
5. Сеть раздает задания “подпишите, что у кошелька А снялось столько-то денег, а у Б столько-то зачислилось. плата за подпись – столько-то”. Тут в дело вступают “майнеры”. Напрягая свои видеокарты, FPGA и ASICи, они с помощью сложных алгоритмов ищут те самые “хеши”, которые подпишут эту транзакцию.
6. Как только “хеши” найдены, операция завершается.

Просто? Да, просто. Но эта простота таит несколько серьезных отличий от привычных вам денег.

1. Открытость. Любой в сети может посмотреть состояние вашего кошелька. Сколько и от кого пришло и сколько и куда ушло.
2. Анонимность. Нет никакого способа связать какой-либо кошелек с кем-нибудь, пока не будет осуществляться ввод/вывод денег в “реальный мир”.
3. Невозможность “отката” транзакций. Если деньги “ушли”, то все. Нет никаких механизмов для исправления ситуации.
4. Возможность создания неограниченного числа кошельков. И восстановление кошельков из “ничего”

Этих четырех пунктов хватило, что бы центробанки любой страны начали напрягаться. В результате где-то уже запретили криптовалюту, где-то разрешили или размышляют. Безучастных не осталось и именно поэтому вам необходимо прежде изучить законодательство вашей страны прежде чем начать активно использовать “крипту”.

Вас это не пугает и вы решили попробовать? Ниже один из вариантов для bitcoin.

1. Необходимо создать кошелек. Напомню, что кошелек – это всего лишь адрес в сети. Сложный, закодированный, но всего лишь адрес. Поэтому вы можете спокойно использовать те программы, которые вам нравятся и не бояться, что в какой-то момент по прихоти автора программы вы окажетесь к ней прикованы.

Так как я рассказываю про биткоин, то самым логичным будет набрать в поисковике “bitcoin wallet” и попасть на официальную страницу. Выбираете тот, который вам больше понравится. Можно одновременно использовать хоть 10 клиентов для одного кошелька – нет никаких препятствий для этого.

Процедура создания кошелька везде одинакова. Программа чего-то там поделает и попросит вас распечатать и сохранить 12 слов на английском (или “посев”-“seed”). Это самые важные слова. Любой, кто имеет их, будет способен получить полный и абсолютный доступ к вашему кошельку. Ну а потом программа покажет вам длинную строчку из кракозябр (типа такой 1Ag6nJXyRKEjnpzsE9D2wjQXCtt65JU5xF), которая и будет вашим “кошельком”.

ВНИМАНИЕ! Первое, что вы должны сделать – это попробовать восстановить кошелек в другой программе. Криптовалюты дело новое, поэтому вполне вероятна ошибка. Вот пример.

Seed из electrum не подходил никуда, кроме самого electrum. На картинке Exodus, но я попробовал и другие. Пришлось пересоздавать уже в другой программе, а на электруме поставить крест.

2. Положить в кошелек денег. Как ни странно, это самая сложная часть. Откуда взять криптовалюту?

Вариантов несколько:
– “Намайнить”. Поставить на компьютер специальные программы, настроить их и потратив кучку электроэнергии, получить искомое. Это отдельная тема и я её не буду освещать тут.
– Заработать/попросить. Тут как в реальном мире. Кто-то, кто имеет криптовалюту, по каким-то причинам переводит вам. На сколько договоритесь, столько и получите.
– Ввести из реального мира через нал или кеш. Это самый сложный и одновременно простой путь, поэтому я опишу его.

В сети есть много бирж, которые готовы обменять ваши деньги в реальном мире на криптовалюту. Но все зашуганы регуляторами на предмет поддержки терроризма, наркотиков и детской порнографии. Поэтому заранее готовьтесь к унижению.

Вам потребуется хорошие сканы или фотографии вашего паспорта. Той страницы, где написано, кто вы и откуда. Скан желательно иметь цветной и что бы захватывал все (то есть все четыре угла были видны и ничего не закрывало)

Так же приготовьте скан какого-либо счета. Счет должен быть свежим, с вашей фамилией и адресом. На счете должна быть печать. Или штрихкод.

И все это желательно должно быть на английском языке. Есть биржи, которые умеют в русский, но их меньше чем не умеющих.

Некоторые еще требуют фотографию, на которой четко видно вашу физиономию и карту, с которой будет произведен платеж.

Эти требования я собрал из тех бирж, куда я сунулся. К сожалению, в моем случае все эти требования совершенно невыполнимы (я прописан в дальнем замкадье, а живу в москве), поэтому мне пришлось идти на рынок. Напишу адрес на русском, что бы не запалили. локалбиткоинс.нет

Реально рынок. Одни частники. Хочешь покупай, хочешь продавай. Налом, с карты на карту, перечислением – как угодно. Всей защиты – репутация продавца и дикие проценты. Повторюсь, больше защиты никакой нет. Поэтому купили (адрес кошелька дадут) – перевод на свой кошелек. Будучи после обеда в хорошем настроении, решил шикануть.

Вот так это выглядит со стороны биржи.

А вот так – со стороны клиента.

Деньги приходят практически мгновенно, но где-то с час они недоступны (смотри на надписи в клиенте). Именно в этот момент “майнеры” по всему миру греют воздух своими дивайсами.

И все, через некоторое время все эти предупреждающие надписи пропадают и вы сможете пользоваться своими деньгами абсолютно точно так же, как и обычными.

Повторю правила.

Открытость. Любой может посмотреть состояние кошелька. Любой вводит номер моего кошелька и видит все. Для просмотра баланса и транзакций надо только адрес-имя кошелька.

Анонимность и невозможность отката.

Вот мне очень хороший человек прислал 0.001 эфира. И 12 других человек подтвердили это. Если они сами не скажут, что эти кошельки принадлежат им – у меня нет возможности узнать, кто они.

Неограниченное число кошельков. Тут предоставляю право проверить вам самим.

Вот так все просто.
ЗЫ 1Ag6nJXyRKEjnpzsE9D2wjQXCtt65JU5xF и 0x4f565Cc6D0ea31Fb88e095A6e8Db9233f3234379 – мои кошельки. Можете переводить сколько угодно денег, я не буду против 🙂

Запрет macOS менять имя машины

admin

Довольно часто я со своим макбуком попадаю в чужие сети. И некоторые (не будем показывать пальцем) в DHCP ответе отдают новое имя машины. А macOS как и положено, меняет свое имя на указанное. Мелочь, но напрягает когда в терминале видишь непривычное имя.

Решение простое: сделать скрипт/выполнить следующие команды. Вместо mbook поставьте свое

NAME="mbook"
sudo scutil --set HostName ${NAME}
sudo scutil --set LocalHostName ${NAME}
sudo scutil --set ComputerName "${NAME}"

Решение простое: DHCP может переписать HostName, но приоритет у LocalHostName и остального выше.

Взгляд на фрилансеров с другой стороны барьера

admin

Потребовалось мне тут сделать одну простенькую, но высокохудожественную штуку. Я здраво оцениваю свои навыки и прекрасно понимаю, что специально обученные люди сделают это лучше, быстрее и дешевле меня.

Ок, где надо искать людей, готовых за толику малую сделать нужное? Правильно, на всяких фриланс-биржах. В русскоязычной части интернета таких вроде две: fl.ru и freelance.ru. Лично у меня в голове на эти два адреса всплывало только то, что это раньше был один ресурс, потом кто-то там куда-то разругался и их стало два. Но это лично мне как заказчику все равно.

Итак, первым в мои руки попал freelance.ru. Восстановил пароль и попробовал поискать фрилансеров. Видимо, мои навыки как-то расходятся с точкой зрения дизайнеров, потому что я регулярно то пытался захантить кого-то, то поставить оценку. А когда я посмотрел на число “свободных” рук по категориям, мне как-то вообще стало грустно.

А вот fl.ru напротив как-то показался более живым. Точно так же восстановил пароль, потыкал во всякие кнопочки и преодолев некоторые внутреннее сомнение “а надо ли?”, создал проект.

Первый ответ был получен буквально в течении пяти минут. Затем еще один … В общем, пошел процесс. И сразу выявились шаблоны, по которым живут фрилансеры.

Самый распространенный вариант – прислать куски из своего портфолио. Без каких-либо комментариев и часто имеющих самое отдаленное отношение к теме проекта. Нет, я понимаю, что лучше один раз увидеть, чем сто раз услышать … В общем, пусть художник и дальше сидит голодным.

Вторым по частоте идет вариант коротенького сообщения. Полностью шаблонного, поэтому приведу его здесь:

Добрый день!
Готов{а} выполнить проект. Я {имею три туалета/занимаюсь этим 100 лет/зажигаю даже гондурас}
Мои работы {ссылка}, если будут вопросы – обращайтесь в скайп best_of_the_best
{Подпись}

Обалдеть. А почему я должен куда-то обращаться и задавать какие-то вопросы? Тем более что на данной стадии у меня вопрос только один “а он{а} сможет?”. И чем плох встроенный чатик?

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

Тут обычно совершается самая тяжелая ошибка: вопросы не задаются. Ни в встроенном чатике, ни в указанных в ответах мессенджерах. Если кто-то думает, что я буду отслеживать “задал ли он вопрос или нет”, то этот кто-то очень глубоко заблуждается.

Отдельной категорией идут сообщения, где сразу указываются цены/сроки. Как ни странно, но они тоже полностью подчиняются описанным шаблонам. И тут уже начинает поднимать голову мой опыт. Ну не бывает так, что бы с первого раза было все понятно “от” и “до”. Не бывает и точка.

Какие сообщения с моей точки зрения наиболее заслуживают внимательного ознакомления?

1. Должно быть подтверждение, что это написано не копипастом. Для этого достаточно зацепиться за любую деталь в описании. Если нет описанной детали, зацепитесь за отсутствующую. Если вы делали такие проекты, то наверняка знаете и кучу “подводных камней”. Откройте хотя бы один для меня.

2. Если даете сроки и деньги, но тогда опишите, за сколько ЧТО вы сделаете. Не просто “сделаю описанное”, а “нарисую/сделаю/офигачу вот это”. В описании я могу иметь в виду что угодно и опустить “известные всем” вещи. Оно вам надо, где-то ближе к концу получить проблемы на ровном месте?

3. Вызовите меня на диалог. И именно в том месте, где мне удобно. И задайте практически любой вопрос по теме. Я прекрасно понимаю, что вы из другой области и имеете полное право не разбираться в тонкостях или наоборот, получаете подтверждение, что я действительно хочу то, что описываю. Разорвать уже установившейся контакт значительно сложнее, чем не просто не ответить на сообщение.

Вроде просто, но почему-то так сложно …

Контроллер версия 2

admin

У меня уже была версия 1, но недавно с испытаний вернулась более новая и улучшенная версия. Теперь она выглядит так:

Это по-прежнему шилд для Arduino Nano, но функционал немного поменялся.

Во-первых, эта версия умеет “распознавать” на входе сигналы уровнем как 220В, так и 24В. При этом без разницы, постоянное или переменное напряжение. Бонусом добавил световую индикацию состояния входов.

Во-вторых, плата теперь имеет два выхода 0-10В. Мелочь, но это очень приятная мелочь.

И наконец, сделал “закладку” для универсального порта. Это маленькая плата-расширение на снимке снизу

Сам порт с испытаний не вернулся, но если все будет хорошо, он обеспечит вход/выход 0-10В, вход-выход 0-20мА и измерение сопротивлений от 100Ом до 100кОм. Разрабатывался в расчете на “закрытие” всех потребностей обычных автоматизаторов. Или говоря другими словами, для тех кому не нужны защиты в 5кВ, гальванические развязки и прочее. Благодаря этому конечная цена данной версии колеблется в районе 2000 рублей в зависимости от объемов.

Но нет пределов совершенству. Скоро будет 3я версия платы, которая закроет найденные недочеты. Например, можно и нужно выровнять реле. И добавить еще немного индикации. И … в общем, все некритично, но практично.

Оригинальный вариант взлома …

admin

Пришло мне тут аж два письма. По содержанию одинаковых, но с разных адресов.

Расчет абсолютно верный: всякие метрики, адворды и прочие маркетинговые фигни требуют разместить очень похожее для подтверждения. Одним меньше, другим больше …

Но проблема только в одном: размещение данного кода приведет к открытию “потрохов” сайта любому желающему.

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

А вот дальнейшее не повторяйте! Я знаю, что делаю и к чему это может привести.

Я создал этот a1iqyyar9p1ep21a.php в домашнем каталоге kaloshin.ru. Посмотрю, что получится 🙂

Кто такие DevOps?

admin

Слово модное…это да!! Но если публиковать как «Системный администратор», то откликаются мальчики-настройщики компов, если «Программист», то жесткие программеры без фантазии © Объяснения одной дамы

Любой, кто интересовался этой темой, знают, что данное сокращение произошло от Development и Operations. Или если перевести на русский – Программисты и Сисадмины. Да, operations дословно переводится не так, но здесь я использую слово «сисадмины» в самом широком смысле.

Кто такие «сисадмины»? Если кратко, то это именно те люди, на руках которых держится вся инфраструктура. Где-то этим словом называют приходящих «аникейщиков», которые меняют картриджи в принтере и изредка чистят компьютеры от вирусов и троянов. А где-то это целые залы людей, разбитых на свои касты. Кто-то занимается сетями, кто-то базами данных, а кто-то обслуживанием датацентров и их инфраструктуры. Титаны антистрессовых методик.

Точно такое же широкое определение имеют и «программисты». И тот, кто пишет на javascript проверку ввода на сайт и тот, кто добавляет код во внутренний модуль корпоративной системы – все они «программисты». И даже тот, кто пишет на встроенном языке 1С, тоже программист, что бы об этом не думали другие.

В чем же основная причина, приведшая к появлению девопсов? Для этого необходимо немного углубиться в специфику работы каждой «секты».

Для сисадмина самое важное это то, что бы вверенная ему система работала без перебоев. Не обращая внимания на тупых пользователей, идиотов-разработчиков, отключения питания и поломок оборудования. Все, абсолютно все, рассматривается с точки зрения надежности. И венцом этой надежности является достижение времени доступности системы в 99,999% (или «5 девяток»). Поверьте, заставить современные системы работать так, чтобы их время недоступности не превышало 5 минут в год – это очень сложная задача. И когда вы добиваетесь, что максимальное время, когда подчиненная система может сказать «ой, я не могу» – это 6 секунд в сутки, то спокойно можете брать с полки пирожок.

У разработчиков же другое положение. Над ними коршунами вьются кровососы-менеджеры, которые постоянно требуют новый функционал, который должен работать быстрее или лучше. И всё это великолепие не должно поломать уже существующий функционал. И код, который прекрасно работает на твоей машине, почему-то отказывается работать как надо даже в тестовом окружении. А еще эти гамадрилы-сисадмины не дают нормально покопаться в получившейся у них системе и понять, что пошло не так даже после успешно пройденных тестов. Эти чудаки на букву «м» постоянно орут как резанные и набрасывают говен на вентилятор при любом чихе. И никто кроме коллег не способен оценить красоты получившегося кода или изящества алгоритма.

А рядом вьются … коллеги из отдела тестирования. Эти вообще постоянно нудят про то, что с говнокодом пора кончать и им опять нужна свежая копия базы данных.

В эту сложную и нервную обстановку добавляет перцу то обстоятельство, что «сисадмины» никогда не писали код размером больше чем на пару страниц, а «разработчики» никогда не обслуживали написанные ими системы (а часто даже и не пользовались ими). Результат абсолютно предсказуемый: тотальное непонимание друг друга и подковёрные войны.

Вот в горниле этих битв и родилось новая каста – DevOps или девопсы. Как водится, поначалу были перегибы с обоих сторон и презрение к «переметнувшимся». Плюс из-за молодости самого термина у него множество толкований и определений. Кто-то считает девопс методологией, направленной на автоматизацию и увеличение числа релизов, а кто-то – на уменьшение ошибок. Я же считаю, что девопс – это прежде всего человек, главной задачей которого является снижение головной боли у программеров, сисадминов и QAшников. А те уже сами напишут, отконфигурят и оттестируют нужное.

Ибо если поглядеть с любой стороны, девопс будет выглядеть как некий недоучка, лишь в редких случаях способный выдать что-то толковое. Бегает со своими скриптами наперевес, чего-то там курочит в коде и лишь принадлежность к «своим» не позволяет его послать в очень далекое эротическое путешествие. У меня нет ни капли сомнения, что программер переиграет девопса в программировании, сисадмин – в администрировании, а тестировщик – на своем тестировочном поле.

Но ценность девопса именно в стоянии нараскоряку в постоянном процессе разрушения стен непонимания между «сейчас зальем, а там разгребут» и «чего там эти опять одноклеточные выделили». Да, сложно, но как показывает практика, вполне возможно.

Сейчас, в самом начале жизни девопсов (с 2009 года же), самой основной их задачей является автоматизация. Объёмы того, что необходимо автоматизировать – поистине ужасающие. Ведь все (программеры и сисадмины) непрерывно трудятся над увеличением завалов не один десяток лет.

Что обычно автоматизируют?
– Развертывание очередного релиза кода. В тест, в стейджинг, в продакшн. Да хоть на машину разработчика. С необходимыми сервисами и данными. Разных версий.
– Обновление. Сервера, сервисы и сайты. Быстро и еще быстрей.
– Управление инфраструктурой. Сегодня 100 серверов в одном датацентре, завтра 500 в трех, а послезавтра 1000 снова в одном. Мониторинг, сбор логов и куча других мелких задач, которые раньше выполнялись вручную или не выполнялись совсем.

Это самые общие задачи. Где-то спектр для автоматизации побольше, а где-то поменьше.

Широкий характер выполняемых задач автоматически формирует и необходимые требования к девопсам:

– Необходимо знать все используемые продукты, языки и технологии. Только тогда стандартная для девопса задача «скрестить ужа с ежом и заставить их летать» автоматически становится выполнимой. Сисадмин сделал бекап? А девопс должен забрать этот бекап, выкинуть из него всякую конфиденциальную информацию и засунуть в систему (которую построил он же), которая позволит разработчикам и тестировщикам без опаски гонять свои творения на «почти продакшене».

– Наличие знаний (есть еще умное слово «компетенций») по всему процессу разработки. Причем знания должны быть реальными и боевыми. Потому что некому кроме девопса остановить программера, когда он решит напрямую засовывать json в обычную базу данных. Для разработчика в этом нет ничего крамольного (база поддерживает? поддерживает!), для сисадмина тоже (ну растет база и требует больше ресурсов – это нормально), а DBA по привычке обматерит всех и молча пойдет строить индексы и партиционировать базу. А то, что полученная конструкция могла быть быстрее и надежней – это никому не интересно. Кроме девопсов.

Нет ни того, ни другого? Тогда получаются люди, которые прекрасно характеризуются как «чуваки с накачанным ЧСВ и недержанием кода».

Требования большие? Да, большие. Зато и награда велика.

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

P.S. Ну и денег дают нормально.

Бекапы – фигня. Восстановление – вот это да!

admin

Пару дней назад все и везде прожужжали мантры про всемирный день бекапа и про то, что делать бекапы – это хорошо. Но почему-то никто нигде не жужжит про то, что бекапы сами по себе, без восстановления – фигня полная. Ну лежит где-то резервная копия, место занимает. И что вы с ней будете делать, если что-то случится? А как до неё доберетесь? А ключи и пароли откуда возьмете? И для любой системы таких вопросов можно задать сотни.

Будь готов!

Именно поэтому я изобрел лично для себя свой личный DIRT (Disaster Recovery Test). Где-то раз в месяц (или чаще, под настроение) я тупо сношу все с ноута и ставлю заново операционку и накатываю назад рабочее окружение. Первые разы длились все выходные и без потерь не обходилось. Зато сейчас мне требуется примерно час, что бы вернуться в строй. Около трех часов – что бы вернуть 100% окружения назад. Быстрее не получается, ибо ограничен скоростью ноутбука и интернета. Максимальные потери – с начала рабочего дня. Все, что мне необходимо на данный момент – это ноутбук и быстрый интернет.

Итак, что необходимо для получения аналогичного?

Во-первых, компьютер с нормальной и привычной вам инфраструктурой. Представьте себя в командировке в далеком городе. У вас сгорает синим пламенем ваш любимый ноутбук. Что делать? Лучшее решение: тупо идем в ближайший компьютерный магазин и покупаем новый ноутбук. Попытка ремонта или привоза “трупика” домой – все это потери времени, а его обычно всегда не хватает. Мой выбор на данный момент – MacBook. Просто, удобно и unix внутри.

Во-вторых, приучите себя использовать систему хранения паролей. Все пароли, ключи, сертификаты или конфигурационные файлы должны быть там. Все, что необходимо вам помнить – это как добраться до этой системы и мастер-пароль. В свое время я выбрал 1Password и ни капельки об этом не пожалел за 5 лет.

В-третьих, приучите себя использовать системы контроля версий. SVN, Git, Mercurial – что угодно, но в этой системе должны лежать все документы и файлы, которые представляют для вас хоть какую-то ценность. Да, поначалу будет тяжело, особенно если вы не представитель ИТшной области. Очень ограниченным паллиативом будет покупка аккаунта в дропбоксе или в другом хранилище файлов. Там тоже появляются возможности про сохранение версий документов и их “отката” при необходимости.

Так же очень полезно завести на каком-нибудь облачном хранилище файлов каталог, в который вы будете складывать дистрибутивы программ. Да, сейчас есть много магазинов приложений (например, встроенный в Apple или Steam. Что-то аналогичное есть у Windows), который после ввода заветного логина и пароля дадут поставить вам все назад. Но до сих пор есть куча приложений, авторы которых по каким-то причинам не могут или не хотят публиковаться в таких магазинах.

И когда вам потребуется поставить такое приложение, то легко можно столкнуться со следующими проблемами:

– Нужной версии уже нет. А доступная версия требует покупки. Да, можно списаться с автором или поискать в интернете, но это потеря времени.
– Для скачивания версии необходимо зарегистрироваться/залогиниться на сайте, потом они пришлют ссылку, по которой скачается “качальщик”, который и начнет скачивать нужное.
– Дистрибутив большой или лежит на медленных серверах. Пока скачаешь …

Наличие своего, персонального архива нивелирует эти проблемы практически одним махом.

И вот только после этого можно поставить какую-нибудь систему резервного копирования (Acronis Backup очень даже, не смотря на мелкие глюки). И натравить её на всё вот это скопом для создания последней “линии обороны”.

Ну и регулярно проводить восстановления накопленного непосильным трудом. Повторюсь, в первые разы вы обязательно что-нибудь потеряете или забудете и это нормально. Еще раз – абсолютно нормально. Это для того и надо, что бы когда это случилось внезапно, у вас был четкий план, что и когда делать.

Вот как у меня происходило это в последний и предпоследний раз (я пролил кофе на ноутбук и просто захотелось)

1. Сносим диск и ставим операционку с нуля.
2. Как только она поставилась, идем в родной магазин приложений и ставим хранилку паролей. Затем клиент для “облачных облаков”.
3. Запускаем все это. Доступ до паролей получен, основные файлы (типа инсталлятора vpn) пошли заливаться на ноутбук.
4. Запускаем установку необходимого из Apple store. Всякие slack, things и прочее.
5. По мере установки всего я уже могу начинать пользоваться ноутбуком. Да, почта не вся засинхронизировалась или индексатор не прошел по всем файлам, но я уже могу что-то делать.
6. Восстанавливаем из системы контроля версий последние проекты и разворачиваем файлы конфигурации.
7. По мере необходимости ставим тот софт, который не требуется “прямо сейчас”, но нужен регулярно.
8. Оцениваем потери и думаем над шагами, которые надо сделать, что бы это не повторилось.

Все. Первый раз сложно, в 10й – просто. Главное тут – регулярность.

Сэм Ньюмен. Создание микросервисов

admin

Дочитал книгу Сэма Ньюмена про микросервисы. Кратко: читать стоит, но аккуратно.

Перед прочтением я специально не стал интересоваться, кто такой автор, где он работал и какой у него опыт. Да и сейчас не буду интересоваться, просто потому что уже составил свое мнение.

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

А вот последние, про тестирование, мониторинг, безопасность и масштабирование … Скажем так, в отличии от первых глав, там налита вода и общие слова. Вот реально никакой конкретики в методах преодоления проблем. И автор явно не мог не знать о них, но таких красивых решений у него не было. Ну как можно строить мониторинг на нагиосе, если он совершенно не приспособлен для постоянно меняющего числа машин? А в безопасности тоже дикая куча проблем связанных с тем же самым. И никакой IDS/IPS/IPTables (да, там именно так, iptables с большой буквы) не поможет в этом.

Скажу честно, у меня тоже нет решений-серебрянных пуль на эти темы. Но почему Сэм не упомянул возможные варианты? Скорее всего потому, что они тупо на них забили …

В общем, слабая 4ка.