Изучаем Vim, команды и макросы. Зачем текстовый редактор Vim в 2018?

Vim — мощнейший текстовый редактор, которому скоро будет 50 лет. Если вы много работаете с текстом, то вполне вероятно Vim сможет значительно облегчить вашу жизнь и упростить написание и редактирование текстов.

Авторизация по SSH ключам в GitLab/Github

git pull/push просит логин и пароль на каждой операции и вы задолбались их вводить? Тогда мы идём к вам:)!

Первое. Генерим ssh ключ:

ssh-keygen -t rsa -b 4096

Второе. Копируем созданный ключ (файл ~/.ssh/id_rsa.pub) в глобальные настройки профиля GitLab (если ссылка не работает, идти в Settings - > SSH Keys).

Третье. Проверяем, что локальный Git репозиторий работает с удаленным сервером через SSH вместо HTTP или HTTPS:

git remote -v

Если вы видите что-то вроде origin git@, то всё в порядке, если нет — переключаемся на SSH ссылку origin-сервера, её можно скопировать на странице репозитория в веб-интерфейсе самого Gitlab или Github:

Меняем удаленный Git сервер для работы через SSH вместо HTTPS:

git remote set-url origin git@gitlab.com:dbms/vetexpert-vuejs-mobileapp

Ура! Теперь команды git pull/push не будут просить логина и пароля.

Работа с Timezone в Django + PostgreSQL

Задача: разобраться, как нормально работать с временными зонами в Django/PostgreSQL.

Решение.
Включить в Django settings.py использование временных зон и указать нужную зону:

USE_TZ=True
TIME_ZONE = 'Europe/Moscow'

Для работы со временем и датой всегда использовать django.utils.timezone.localtime:

from django.utils import timezone
now = timezone.localtime(timezone.now())

Дело в том, что timezone.now() отдает время в UTC метке и тут можно напороться на два не очень удобных момента: в 2 часа московской ночи timezone.now().date() покажет неверную дату, и время timezone.now().hour — не текущий час в Москве, а текущий час по UTC. Поэтому всегда используем timezone.localtime() для получения нормального Московского времени.

PostgreSQL в связке с Django по умолчанию хранит все временные метки timestamp в UTC временной зоне и при использовании ORM установленная в Django временная зона перегоняется в UTC и в базе хранится как UTC.

Использование localtime() прекрасно — в Python коде мы уверены, что это всегда именно локальное нормальное время и дата.

Бесплатное получение Dun & Bradstreet D-U-N-S Number для регистрации в Apple Developer

Проблема: хотим выложить приложение в Apple App Store от имени компании. Для этого надо зарегистрировать Apple Developer аккаунт, заплатить в Apple 99$ (ежегодно) и в процессе регистрации предоставить специальный номер Dun & Bradstreet D-U-N-S Number, который выдаёт компания Dun & Bradstreet, ведущая международный реестр организаций. В России получить такой номер стоит 12 тысяч, а нам очень не хочется платить эти деньги непонятно за что.

Решение. Apple сама бесплатно может передать данные в Dun & Bradstreet и получить номер D-U-N-S за вас. Для этого идём в https://developer.apple.com/enroll/duns-lookup/#/request, вводим свой Apple ID логин и пароль, заполняем на открывшейся странице данные о компании.

Заполнив, в самой нижней части страницы нажимаем еле заметную, спрятанную от врагов, ссылку submit your information.

После этого отправляем данные, на все соглашаемся и ждём.

Ура!

Отзывы о DBMS

Привет, друзья!
Решил собрать отзывы о нашей работе (я являюсь руководителем компании DBMS). Будем продолжать снимать новые:)

SSH авторизация и доступ по ключу без пароля

Как мы обычно проходим SSH авторизацию?

ssh root@server.ru

Затем ищем где-то пароль, копируем его, и, если всё успешно, попадаем на сервер. Какие проблемы есть с таким подходом?

Во-первых, конечно, под root заходить на сервер сразу по SSH затея плохая и такую возможность надо сразу отключить, это опасно. Поэтому: а) создаём пользователя, например, www; б) даём ему возможность логиниться на сервер по SSH; в) логиниться root пользователю по SSH запрещаем:

# создаём юзера www
adduser www
# позволяем ему выполнять sudo команды с root правами
adduser www sudo
# позволяем ему заходить по SSH, а root пользователю запрещаем
vi /etc/ssh/sshd_config
AllowUsers www
PermitRootLogin no

# выходим из vi, перезагружаем SSH сервер
sudo /etc/init.d/ssh start

Теперь зайти по SSH под пользователем root на сервер мы не сможем, но можем зайти под пользователем www, который сможет выполнять команды с правами root, используя sudo, например, sudo vim /etc/hosts.

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

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

Генерируем ключи и переносим их в ~/.ssh/:

mkdir keys; cd keys;
ssh-keygen -t rsa -f www
mv www* ~/.ssh/

Команда спрашивает пароль на ключ, вводим произвольный пароль. Создастся два файла:

• ~/.ssh/id_rsa.pub - публичный ключ, который копируется на сервер;
• ~/.ssh/id_rsa - закрытый ключ, который остаётся у нас.

ssh-copy-id -i ~/.ssh/www www@server.ru

Запрашиваемый пароль - это пароль доступа пользователя www на сервер, то есть заданный при создании пользователя www. Если SSH на сервере на нестандартном порту, то нужно передать порт следующим образом:

ssh-copy-id '-p 443 www@server.ru'

Теперь можно заходить на сервер без ввода пароля:

ssh www@server.ru

Если сервер не имеет домена (доступ только по IP), то, чтобы не копировать каждый раз IP, можно упросить авторизацию, создав команду логина и выполняя её:

vim ~/.bashrc
alias ssh_www_server='ssh www@server'

Перезапустим терминал, появится команда ssh_www_server, которая быстро и безопасно пустит нас на сервер - без копипаста IP сервера и пароля на SSH:

ssh_www_server

Django & PostgreSQL & ERROR: duplicate key violates unique constraint

Часто при использовании PostgreSQL после перетаскивании БД с одного сервера на другой (или с локальной dev машины на production) начинают сыпаться primary keys, выдавая при insert операциях что-то вроде:

ERROR: duplicate key violates unique constraint

Дело в том, что, если, например, MySQL использует для первичных ключей autoincrement поля, которые просто увеличиваются на 1 при добавлении в таблицу каждой новой строки, то PostgreSQL использует для первичных ключей поля типа serial, которые фактически являются просто цифровыми полями, значения которых берутся из PostgreSQL последовательности (sequence). При этом если следующее значение последовательности равно 100, а id=100 в таблице уже есть, то и возникает конфликт duplicate key:

SELECT MAX(the_primary_key) FROM the_table;
SELECT nextval('the_primary_key_sequence');

Если эти первое значение больше второго или равно ему - есть проблема. Чтобы исправить ситуацию, можно установить значения всех последовательностей на заведомо большое число (которое больше всех текущих id на порядок, например), но это некрасиво и неудобно, быстрее попросить Django помочь нам. Такая короткая стандартная Django команда выведет весь SQL, который скорректирует проблему, установив корректные значения для PostgreSQL последовательностей:

./manage.py sqlsequencereset app1 app2

app1, app2 здесь - это названия Django приложений. Полученный SQL код можно просто выполнить в БД и всё - вот так просто. Django рулит!