Ростелеком: постоянные обрывы соединения

Категории: HowTo

Все было бы нормально если бы не одно но.

Адсл-модем уверенно устанавливал соединение и. И что самое интересное просто так обрывал pppoe-коннект с фразой “pppoe connection terminated unexpectedly”.

Расследование показало, что перед тем, как соединение будет сброшено в лог (что немаловажно в отладочный дл которого надо повысить уровень отладочных сообщений до dbg) падало сообщение о том, что “no response on 3 echo requests”.

Выяснилось следующее:

  • падение происходило каждые полторы минуты
  • в конфиге для текущего соединения найдена строка lcp echo 30 3

О как! Оказывается, что модем проверяет жизнеспособность соединения при помощи lcp-запросов, а выяснилось, что ростелекомовский adsl их рубит сразу.

Вывод: отключить lcp echo и проверять наличие соединения пингами.

Для zyxel keenetic нужно будет зайти по telnet и выполнить набор команд

(config)> interface PPPoE0  
(config-if)> no lcp echo  
(config-if)> exit  
(config)> system config-save  
(config)> exit

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

Yum: поиск пакетов установленных из какого-то репозитария

Категории: HowTo 
$ yumdb search from_repo repoid

http://james.fedorapeople.org/yum/commands/find-repos-of-install.py

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

Категории: Разработка HowTo

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

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

Предположим, что все проекты у нас будут собраны в доменной зоне *.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
``````shell
$ 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 - решается выполнением shell $ 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

```shell
git config --bool core.bare true

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

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

git init --bare