Forum Debian Users Gang

Jako, że umknęła jedna ważna rzecz, to wypadałoby o niej coś napisać. Dziś aktualizowałem sobie wheezy na unstable (nie mam pojęcia skąd mi się coś takiego starego wzięło) i podczas instalacji został wyrzucony komunikat o udev'ie. Chodziło tam o takie coś:

Debian releases up to 8 ("Jessie") and Ubuntu up to 15.04 had an udev rule
/lib/udev/rules.d/75-persistent-net-generator.rules which fixed the name of a
network interface that it got when its MAC address first appeared in a
dynamically created /etc/udev/rules.d/70-persistent-net.rules file.

This had inherent race conditions (which sometimes caused collisions and
interface names like "rename1"), required having to write state into /etc
(which isn't possible for read-only root), and did not work in virtualized
environments.

This old schema is deprecated in Debian 9 ("Stretch"), and will not
be supported any more in Debian 10.

-- /usr/share/doc/udev/README.Debian.gz

Jak można wyczytać w tym pliku, za dwa wydania ten obecny system nazewnictwa nie będzie wspierany przez debiana. Systemd już go nie wspiera zatem lepiej zacząć migrować na nowy system nazw. Choć mnie te domyślne nazwy trochę przerażają: wlp3s0b1 czy enp2s0. xD Ja właśnie sobie zmigrowałem i na dobrą sprawę to niewiele musiałem zmieniać, bo wszystkie aplikacje korzystają z interfejsu bond0 i tylko wystarczyło port przepisać by te wszystkie fizyczne interfejsy do tego bond0 podpiąć. Zaleta korzystania z interfejsów bond. xD

Hepita napisał(-a):

Okazało się że mam to w zakładkach xD prosta regułka udeva https://wiki.archlinux.org/index.php/Network_config … e_device_name

A ja w kompie:

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:1d:c4:82:87", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="lan"

# PCI device 10ec:8169 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:94:f6:02:eb:d7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="net"

:D

Udało mi się zaprogramować mój system, by był w stanie ograniczać aplikacje użytkowników via cgroups. Choć teraz mam dwa mechanizmy i one działają w sumie równolegle. Jeden jest od systemd i można kontrolować usługi via pliki .service. Drugi zaś jest za sprawą pakietu cgroup-tools .

Jeśli ktoś chciałby się tym pobawić, to potrzebuje doinstalować pakiet cgroup-tools oraz stworzyć sobie dwie usługi:

/etc/systemd/system/cgrulesengd.service

[Unit]
Description=Control Group configuration service
Documentation=man:cgconfigparser man:cgclear
ConditionDirectoryNotEmpty=/sys/fs/cgroup/
ConditionPathIsReadWrite=/etc/cgconfig.conf
DefaultDependencies=no
Before=basic.target shutdown.target
After=local-fs.target
Conflicts=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/cgconfigparser -l /etc/cgconfig.conf -s 1664
ExecStop=/usr/sbin/cgclear -l /etc/cgconfig.conf -e

[Install]
WantedBy=sysinit.target

/etc/systemd/system/cgconfig.service

[Unit]
Description=CGroup Rules Engine
Documentation=man:cgrulesengd
ConditionPathIsReadWrite=/etc/cgrules.conf
DefaultDependencies=no
Requires=cgconfig.service
Before=basic.target shutdown.target
After=local-fs.target cgconfig.service
Conflicts=shutdown.target

[Service]
Type=simple
ExecStart=/usr/sbin/cgrulesengd -n -Q

[Install]
WantedBy=sysinit.target

Do tego są potrzebne dwa pliki konfiguracyjne:

/etc/cgconfig.conf z blokami podobnymi do tego:

group users/firefox {
    perm {
        task {
            uid = root;
            gid = root;
        }
        admin {
            uid = root;
            gid = root;
        }
    }
    cpu {
        cpu.shares = "512";
    }
    memory {
        memory.limit_in_bytes = 300M;
    }
}

/etc/cgrules.conf z linijkami typu:

*:firefox            cpu,memory,net_cls    users/firefox/
*:firefox*            cpu,memory,net_cls    users/firefox/

I to w zasadzie wszystko. Poniżej test:

# cat /sys/fs/cgroup/memory/users/firefox/tasks | wc -l
41

# cat /sys/fs/cgroup/memory/users/firefox/memory.limit_in_bytes
314572800

# cat /sys/fs/cgroup/memory/users/firefox/memory.usage_in_bytes
314462208

# cat /sys/fs/cgroup/cpu/users/firefox/cpu.shares
512

oraz

# cat  /proc/`pidof firefox`/cgroup
9:memory:/users/firefox
8:perf_event:/
7:net_cls,net_prio:/
6:cpuset:/
5:freezer:/
4:blkio:/user.slice/user-1000.slice/session-1.scope
3:cpu,cpuacct:/users/firefox
2:devices:/user.slice
1:name=systemd:/user.slice/user-1000.slice/session-1.scope

Wyszło dużo prościej niż w przypadku tych skryptów sysvinit. xD

Ważne tylko by to systemd montował /sys/fs/cgroup i nie określać bloku mount { }  w /etc/cgconfig.conf , bo wtedy będą problemy z montowaniem. Tak poza tym, zdaje się to działać wedle oczekiwań. Choć jeszcze muszę porobić trochę testów i dostosować konfigurację ale myślę, że nie będzie jakichś większych niespodzianek. xD

Ostatnio edytowany przez morfik (2015-12-08 22:03:06)

Ja generalnie to zasoby ograniczam sobie przez systemd, przynajmniej systemowych usług. xD Przykład:

Nice=
IOSchedulingClass=
IOSchedulingPriority=
CPUShares=
StartupCPUShares=
TasksMax=
MemoryLimit=
BlockIOWeight=
OOMScoreAdjust=

I tam jest tego jeszcze trochę więcej ale ja głównie korzystam z tych wyżej. Sam widzisz, że nadanie odpowiedniego priorytetu procesowi czy ograniczenie mu zasobów w systemd nie jest niczym skomplikowanym. xD

Tu problem był taki, że to działa świetnie z systemowymi usługami czy demonami ale w dużej mierze nie działa wcale w przypadku usług i procesów zwykłych użytkowników, zwłaszcza ten cgroups. To powyższe co dałem wyeliminowało ten problem i teraz cgroups w systemd jest w stanie również obrabiać procesy użytkowników. xD

Teraz to u mnie działa mniej więcej tak jak u ciebie. Z tym, że w oparciu o systemd i nie wywala tego całego mechanizmu, który jest dostępny w systemd. Dalej będę wszystkie systemowe usługi ograniczał przez systemd, bo to o wiele wygodniejsze. Natomiast pozostałe będą lecieć przez cgrulesengd

Na serwer niezłe, ale jak w sesji użyszkodnika chodzi np 45 programów, które muszą mieć różne limity, to SystemD/OpenRC nic nie poradzi, i tak trzeba rzeźbić w konfigach cgconfig, co jest 5 razy trudniejsze, niż rzeźbienie w skrypta, który takie grupy stworzy używając trzech poleceń powłoki: mkdir, echo, chmod.

Czemu trudniejsze? Przykład:

group users/firefox {
    perm {
        task {
            uid = root;
            gid = root;
            dperm = 775;
            fperm = 664;
        }
        admin {
            uid = root;
            gid = root;
            dperm = 775;
            fperm = 664;
        }
    }
    cpu {
        cpu.shares = "512";
    }
    memory {
        memory.limit_in_bytes = 512M;
        memory.soft_limit_in_bytes = 128M;
    }
    net_cls {
        net_cls.classid = 0x00010003;
    }
}

Masz tutaj mkdir, touch, chown, chmod, chgrp, i echo. Chyba dokładnie to samo co miałeś u siebie w skrypcie. Co tu do ogarnięcia? xD

Bezcenne w wypadkach, jak np trzeba kilka wersji PHP odpalić równocześnie, albo jakiś demon lubi czasem zdychać nagle, a jest niezbędny.
Automatyczne restart demona po upadku można zrobić w SystemD,  ale w Daemontools każdy program ma swojego "anioła stróża", który go pilnuje.

No systemd ma programowego watchdoga na takie procesy, i jak zdechną to się resetują kilka razy w określonym interwale czasowym (do konfiguracji zarówno ilość resetów jak i interwał nawet per usługa). W sumie to mi się jeszcze nie zdarzyło by ten mechanizm nawalił. Także jest w miarę stabilny. xD

No ja wiem, jak wygląda twój skrypt od cgroups. xD Zajrzyj sobie do "man cgconfig.conf" i popatrz po przykładach. Ten plik robi dokładnie to samo co twój skrypt. xD

SystemD ma watchdoga?

Wykorzystuje w sumie dwa. Jeden sprzętowy, do którego jest podpięty sam systemd, a drugi programowy per aplikacja. Dzięki temu, jak padnie aplikacja, to systemd ją podniesie, a jak padnie systemd, to sprzętowy watchdog go podniesie. xD

Pianie dodatkowych skryptów jest bez sensu, no bo przecie jak ci usługa padnie, to zwykle chcesz ją odpalić za pomocą tego polecenia w usłudze i to robi systemd.

W SystemD pewnie też się da, ale zabawy z tym jest dużo więcej, prawda?

Wszystko się da raczej, tylko trza znaleźć rozwiązanie. xD Zawsze skrypt można wywołać z usługi jak prościej się nie da.

Że też takie starocie w debianie trzymają: xD

Stable release     0.76 / July 12, 2001; 14 years ago[1]

W każdym muzeum znajdziesz masę działających rzeczy, co nie oznacza, że warto zachęcać innych do korzystania :)

Będzie działać, aż nagle przestanie i raczej nikt tego już nie poskłada.

yossarian napisał(-a):

W każdym muzeum znajdziesz masę działających rzeczy, co nie oznacza, że warto zachęcać innych do korzystania :)

Będzie działać, aż nagle przestanie i raczej nikt tego już nie poskłada.

Będzie działać jeszcze wiele lat.

Rzeczy w muzeum są materialne, tu się coś złamie, tu przetarło,
a poluzowało.
Tymczasem w informatyce zawsze możesz dany kod przekompilować z nowymi libami, i jest jak nowy.

A w Gentusiu tak:

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

depend() {
    use net
    before ntpd ntp-client spamd apache apache2
}

start() {
    ebegin "Starting service scan"
    setsid start-stop-daemon --start --exec /usr/bin/svscan \
        --background --make-pidfile \
        --pidfile /var/run/svscan.pid -- /service
    eend $?
}

stop() {
    ebegin "Stopping service scan"
    start-stop-daemon --stop --exec /usr/bin/svscan \
        --pidfile /var/run/svscan.pid
    eend $?

    ebegin "Stopping service scan services"
    svc -dx /service/* 2>/dev/null
    eend $?

    ebegin "Stopping service scan logging"
    svc -dx /service/*/log 2>/dev/null
    eend $?
}

Jak widać, skrypt startowy z 2004 i chodzi. :D

morfik fajny tutorial juz zaczynałem się uczyć właśnie od niego aczkolwiek pomimo chęci przejścia poniekąd przymusowego na systemd (wheezy > jeesie)  nie dałem rady niestety na mojej maszynie, mam nvraid w szyfrowanym kontenerze i systemd wywalił się gdzieś pośrodku, spróbowałem następnego podejścia z devuan-em i od palca wszystko poszło, zamieniłem tylko sobie sysv na openrc i bardzo ładnie chodzi..zaczynam rozumieć hejterów systemd;)

Ostatnio edytowany przez hi (2016-03-24 18:24:24)

morfik napisał(-a):

Poza tym, nikt cie nie zmuszał do przejścia na systemd/openrc bo debian wspiera sysvinit, także przeznacz czas, który poświęcasz na rozumienie hejterów systemd, na naukę debiana, w szczególności na fakt instalacji w nim systemu inicjalizacji procesów.

wiem wiem, że nikt mnie nie zmuszał i nie mam żadnych pretensji ani hejtów do systemd, chciałem po prostu zobaczyć z czym to się je i po części z ciekawości jako, że narosło sporo kontrowersji wokół tego initu ale stety-niestety na mojej konfiguracji systemd się wywalił to sięgnąłem w pierwszej kolejności po inne rozwiązanie i okazało się działające, nie mam czasu na dłubanie w jakimś wynalazku, który mi nie zadziałał tym bardziej, że na wyciągnięcie ręki mam działające rozwiązania:)

Ostatnio edytowany przez hi (2016-03-25 10:52:12)