Разработка, HowTo

Локальный DNS для разработчика

Итак. У нас море проектов, море виртуалок. И мы хотим как-то удобно с этим всем работать.

Мне по нраву выделять отдельную доменную зону для всех своих виртуалок и подключать к ней нужные адреса.

Предположим, что все проекты у нас будут собраны в доменной зоне *.dev (удобно же).

И каждый из них будет резолвиться по разным адресам.

Составим для себя список хотелок:

  • машины поднимаются вагрантом или еще какой системой (это не так уж и важно)
  • после появления машины в сети ее ip связывается с доменом проекта, который на ней крутится
  • после завершения привязка уделяется

Начинаем хотелки реализовывать.

Ставим named

$ sudo yum install named

Заставляем его слушать только локалхост (он же девелоперский).

Для этого редактируем named.conf и добавляем в раздел options

    listen-on port 53 { 127.0.0.1; };
    listen-on-v6 port 53 { ::1; };

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

Добавляем подключение описания в named.conf

zone "dev" IN {
    type master;
    file "named.dev";
    allow-query {any;};
    allow-update {
        127.0.0.1;
        ::1;
    };
};

В этом описании мы сразу же видим раздел allow-update, который позволяет удаленно изменять зону при помощи команды nsupdate. Разрешаем правку только с локалхоста.

Теперь непосредственно сам файл зоны прямого преобразования — /var/named/named.dev

$ORIGIN dev.
$TTL 86400    ; 1 day
@            IN SOA    dev. rname.invalid. (
                4          ; serial
                86400      ; refresh (1 day)
                3600       ; retry (1 hour)
                604800     ; expire (1 week)
                10800      ; minimum (3 hours)
                )
            NS    dev.
            A    127.0.0.1
            AAAA    ::1
*        IN    A    127.0.0.1

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

Все. Нам осталось перезапустить.

$ sudo service named restart

Проверяем

$ nslookup test.dev 127.0.0.1
Server:        127.0.0.1
Address:    127.0.0.1#53

Name:    test.dev
Address: 127.0.0.1

 

 

Кдасс. А как нам связывать домен с адресом?

Для этого нам нужен скрипт.

#!/bin/bash
TTL=86400
RECORD=$1
IP=$2
(
 echo "server dev."
 echo "zone dev"

 echo "update delete ${RECORD} A"
 echo "update add ${RECORD} ${TTL} A ${IP}"
 echo "send"
) | /usr/bin/nsupdate

 

Пробуем

$ ./named.sh test.dev 1.1.1.1
$ nslookup test.dev 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	test.dev
Address: 1.1.1.1

Возможные проблемы:

  • неправильно установлены права на папку /var/named
  • неправильно указан адрес с которого можно обновлять зону
  • запрет в selinux — решается выполнением
    $ sudo setsebool -P named_write_master_zones 1

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

Найдено в сети

Полезные ссылки

Алгоритмы

Python

PHP

  • Парсинг PHP в Go — основа для построения статических анализаторов и других удобных инструментов

JavaScript

Linux

Git

Софт

Arduino/Raspberry Pi и другое железо

Всякое

Разработка

Git: выделяем глобальный репозитарий для проекта

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

$ git push origin master
Counting objects: 30, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 3.31 KiB | 0 bytes/s, done.
Total 17 (delta 4), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /project/path
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/project/path'

Вообще почему она возникает-то? Разве гит это не распределенная система контроля версий? Распределенная и даже чутка децентрализованная. Совсем-совсем распределенная. А это значит, что пушить изменения можно не только на одно хранилище, а вообще в любой репозитарий. Хоть чуваку за соседний комп. Таким образом разработчикии могут делиться своими наработками.

Но это подразумевает один нюанс: нельзя пушить в ту ветку удаленного репозитария с которой сейчас идет работа.

Суть сообщения в том, что в удаленном репозитарии ветвь, которую мы хотим запушить сейчас, активна (т.е. сделан чекаут на удаленной машине).

А значит и правки в эту ветвь якобы удаленной машиной вносятся (слава роботам!).

Способ первый. Мы заходим в репозитарий и просто чекаутим другую ветку проекта. Профит. 🙂

Способ второй. Мы узнаем, что существует два типа хранилищ: bare и non bare. Дефолтно при выполнении git init будет создано хранилище второго типа (и при чекауте чужого репощитария так же создается локальный non-bare репозитарий).

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

Гитхаб предоставляет хранилища именно такого типа.

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

А что делать?

Если реп у нас удаленный и для совместной работы — конвертируем его в bare

git config --bool core.bare true

Если нет — смотрим выше.

А еще можно сказать иниту, чтобы создавал bare сразу.

git init --bare
HowTo

Unknown keycode 0x0

Unknown keycode 0x0Вот такая веселая надпись будет нас ожидать в gnome если установлена раскладка отличная от en_*.

Это есть глобальная проблема большинства java-приложений в linux — в них не работаю горячие клавиши в раскладке отличной от латиницы (русской и любой другой).

От этого страдают все: и простые пользователи LibreOffice, и разработчики, которые вынождены пользоваться всякими разными ide, которые написаны на java.

Ага. А лечить-то как?

Для продуктов jetbrains существует два рецепта:

Добавить в idea.properties

-Dide.non.english.keyboard.layout.fix=true

Раньше работало, а теперь, увы, нет.

И второй способ, который можно использовать не только с jetbrains, но и с любым другим софтом на java.

Достаточно скачать маленький jar с гитхаба и следовать инструкции. Пока этот способ работает.

Проблема также замечена в smartsvn.

cat phpstorm.vmoptions