November 25th, 2016

404

sid+dist-upgrade+nvidia = боль

Традиционная. Опять конфликт между xserver-abi и nvidia, и я не посмотрел, и сказал "y". Оно посносило x'ы и nvidia, радостно. Откатиться было некуда (т.к. в мирроре только новые). Пришлось качать со снапшотов, при этом cinnamon падает, сижу на xfce4.

Смотрите на то, что dist-upgrade предлагает, прежде чем -y отвечать.

Интересно, а есть ли метод сказать "ни в коем случае не удалять этот пакет при апдейтах"?
404

как выглядит сломанный debian sid


apt-cache policy libc6:i386
libc6:i386:
Installed: 2.24-5
Candidate: 2.24-5
Version table:
*** 2.24-5 500
500 http://mirror.yandex.ru/debian sid/main i386 Packages
500 http://snapshot.debian.org/archive/debian/20161104T152748Z sid/main i386 Packages
100 /var/lib/dpkg/status
2.19-18+deb8u6 500
500 http://mirror.yandex.ru/debian stable/main i386 Packages
amarao@home:~$ apt-cache policy libc6
libc6:
Installed: 2.24-5
Candidate: 2.24-6
Version table:
2.24-6 500
500 http://mirror.yandex.ru/debian sid/main amd64 Packages
*** 2.24-5 500
500 http://snapshot.debian.org/archive/debian/20161104T152748Z sid/main amd64 Packages
100 /var/lib/dpkg/status
2.19-18+deb8u6 500
500 http://mirror.yandex.ru/debian stable/main amd64 Packages
404

(no subject)

Я его-таки оборол на 5ГГц коннектиться вместо 2.4.
[connection]
id=Auto Office
uuid=a1bf3976-b2f9-11e6-990b-6347ffa4cc84
type=wifi
permissions=
secondaries=

[wifi]
mac-address=10:0B:A9:B3:16:48
mac-address-blacklist=
mac-address-randomization=0
mode=infrastructure
seen-bssids=
ssid=Office
band=a
channel=48

[wifi-security]
auth-alg=open
group=
key-mgmt=wpa-psk
pairwise=
proto=
psk=OtItNiOmJul6

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto


Упор - band='a', channel=48.
404

testinfra

Открыл для себя testinfra. Писаю восторгом от кипятка.

import  testinfra
from testinfra.main import main
import pytest

@pytest.fixture
def conn():
    conn = testinfra.get_backend("ssh://cpl.drive.google.com", sudo=True)
    return conn

def test_passwd_file(conn):
    passwd = conn.File("/etc/passwd")
    assert passwd.contains("root")
    assert passwd.user == "root"
    assert passwd.group == "root"
    assert passwd.mode == 0o644


def test_nginx_is_installed(conn):
    nginx = conn.Package("nginx")
    assert nginx.is_installed
    assert nginx.version.startswith("1.2")


def test_nginx_running_and_enabled(conn):
    nginx = conn.Service("nginx")
    assert nginx.is_running
    assert nginx.is_enabled

main()
404

Побудь резиновой уточкой, интернет

Мне нужно написать код, который берёт список каталогов и запускает из них тесты для сервера. Тестам надо передать информацию о сервере: ssh-ключ, имя пользователя, IP, параметры, с которыми сервер (виртуалка) был(а) запущен(а) (например, ожидаемый размер диска и памяти и т.д.).

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

Цели
* Минимизировать количество повторяющихся строчек тесте. Т.е. никаких "распарсить переменные среды окружения" в каждом из тестов.
* Отвязать тесты от потрошков запускающей софтинки. Наивная идея - с inject'ом данных в namespace модуля не катит, потому что хочется дать некоторую свободу в тестировании.

Пока у меня идеи:
1. Модуль-getter, который может импортнуть тест. Т.е. делаешь import testdata, и там уже всё разложено готовенькое, быть может, даже с фикстурами для тестов, и без фикстур, как хочется.
2. Маленький сниппет для парсинга переменных среды окружения.

Для понимания: тесты запускаются не напрямую, а коллектятся testinfra, который юзает для этого py.test, то есть там несколько уровней абстракции.

Пока что мне нравится идея модуля-с-настройками, потому что в тесте можно тогда написать что-то вида:

from testdata import ssh, flavor
def test_server_disk(ssh, flavor):
with connection(testdata.ssh) as conn:
assert conn.Disk.size == testdata.flavor.disk_size

(сейчас проверю, работает ли трюк с вызовом фикстур из модуля).

Работает. Видимо, так и буду делать.

Теперь следующий вопрос: как выглядит эта фикстура? Глобальные переменные или просто честно парсить переменные среды окружения? Перменные среды окружения мне больше нравятся, потому что позволяют разорвать "родственную связь" между моим приложением и тестами, которые в общем случае могут писаться на любом языке.

Более того, само описание тестов можно сделать более общим. Например, поддерживать pytest как один из частных случаев, и shell как другой. Для shell соглашение будет по коду возврата, для pytest'а - по логике самого pytest'а.