28.10.2022 12:30 - 15:00 Uprade z verzie sarge na etch

Server nebol spravovaný 15 rokov čo som tu nebol. Najprv som si pozrel poštu. Bolo tam tam 45,000 mailov v schránke A 20,000 mailov v spame. Spam som zmazal kompletne celý. Zvyšok mailov som pomazal ručne. Boli tam dva zaujímavé zvyšok alebo info maily z firiem kde som si zadal odber. Nasledovalo vymazanie všetkých starých učiteľov a žiakov.

Konečne som sa dostal k nejakému pokroku. Postupoval som podľa toho návodu. V /etc/apt/sources.list som doplnil odkaz na distribúciu etch.

deb http://archive.debian.org/debian etch main contrib non-free

Nasledne som aktualizovoal zoznam balíkov a urobil základný upgrade. A nakoniec aj kompletný upgrade na nové distro

apt-get update apt-get upgrade apt-get dist-upgrade

Výsledkom bolo že sa systém sarge ugradoval na etch


08.11.2022 12:30 - 14:40 Uprade z verzie etch na lenny

Osvedčená metóda z predošlého upgrade narazila pomerne skoro nakoľko libc stiahnutá z repozitáru lenny vyhlásila že vyžaduje minimálne jadro verzie 2.6 Naledoval návrat na etch a pokus nainštalovať posledný kernel z tohoto repozitáru. Problém ale bol že tento kernel nenabehol nakoľko nebol rozpoznaný SCSI radič a tým pádom ani pripojené disky s linuxovým zväzkom.

Nezostalo nič iné než stiahnuť zdrojové súbory pre kompiláciu jadra. A nové jadro skompilovať. Postupoval som podľa toho návodu a kupodivu to aj fungovalo. Najpr nainštalovať balík so zdrojovými súbormi jadra. Súbor sa nainštaľuje spakovaný do /usr/src/linux-source-2.6.24.tar.bz2. Takže ho treba následné rozbaliť.

apt-get install linux-source-2.6.24 cd /usr/src tar xjf linux-source-2.6.24.tar.bz2 cd linux-source-2.6.24

Teraz treba skompilovať kernel. Pred kompilácoiu bolo potrebné ešte nainštaľovať balík libncurses5-dev. Potom ešte skonfigurovať kernel. V podstate som v konfigurácii nič nemenil len som skontroloval či je nastavený typ procesoru Pentium III a či je tam podpora pre SCSI disky a podpora pre radič Adaptec AIC7xxx support (old driver).

apt-get install libncurses5-dev make menuconfig

Kompilácia je týmto postupom

make-kpkg clean fakeroot make-kpkg --initrd --revision=custom.1.0 kernel_image dpkg -i ../linux-image-2.6.24_custom.1.0_i386.deb
po skompilovaní to vyrobí inštalačný balík, ktorý sa nasledovným príkazom nainštaluje. Tam bol problém že síce mi to spustilo lilo ale nový kernel mi to tam nepridalo. Takže bolo potrebné manuálne pridať nový kernel do /etc/lilo.conf a spustiť lilo. Potom už len reštart a výber nového jadra 2.6.24

Zvyšok je už klasika ako sa robila predošlý upgrade

apt-get update apt-get upgrade apt-get dist-upgrade

Výsledkom bolo že sa systém etch ugradoval na lenny


10.11.2022 07:30 - 14:30 Uprade z verzie lenny na squeeze

Tu som po nastavení repozitáru na squeeze tiež pomerne rýchlo narazil. Síce zbehlo update a upgrade ale dist-upgrade už zdochlo na nejakú nekompatibilitu v balík apache2. Skúšal som kde čo ale správne riešenie bolo odinštalovať balik apache ktorý sa tam ešte povaľoval. No a potom už inštaláciia fičala až do balika udev, ktorý vyhlásil že potrebuje kernel minimálne 2.6.26. Zistil som že pre túto verziu je k dispozícii linux-source-2.6.32. Takže rovnaký postup ako predošlá kompilácia. Výsledkom je nový kernel, ktorý nabehol bez problémov a pokračujem v upgrade. Upgrade skončil úspešne, ale po reštarte už nešlo porihlásiť po sieti. A prihlásenie z konzoly bolo divné, nechcelo to totiž žiadne heslo. Kontrola systému rýchle ukázala že neboli rozpoznané sieťové karty. Opäť som teda skontroloval konfiguráciu kernelu a zistil som že ovladač sieťovej karty nebol zahrnutý do kompilácie lebo ho presunuli do nového podpriečinka.

Problém so sieťovou kartov bol v konfigurácii jadra v časti ovládačov. V podsekcii Device Drivers ---> Network device support ---> Ethernet (10 or 100Mbit) je potrebné povoliť EISA, VLB, PCI and on board controllers ---> Intel(R) PRO/100+ support

Problém prihlasovania bez hesla sa zase týkal pam. Počas preinštalácie sa spustila konfigurácia ale z nejakého záhadného dôvodu nebol povolený unixový spôsob overovania užívateľov. Takže som nanovo spustil konfiguráciu pam overovania pomocou príkazu

pam-auth-update
kde som povolil možnosť Unix authentication

Pretože som odinštaloval balik apache a zostal tam len apache2 a ten nebol nakonfigurovaný, tak sa zobrazovala nesprávna stránka ktorá bola v adresári /var/www Tak isto sa nezobrazovali stránky užívateľov. Konfigurácia je v /etc/apache2 Konkrétne treba upraviť /etc/apache2/sites-available/default. Treba tam upraviť východzí adresár stránky na nový SCSI disk. To isté aj pre /etc/apache2/sites-available/default-ssl

ServerAdmin peter@spsest.sk DocumentRoot /newscsi/var/www Options FollowSymLinks AllowOverride None Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all ErrorLog ${APACHE_LOG_DIR}/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined
a2enmod userdir service apache2 restart
Ešte treba pridať modul na zobrazovanie užívateľských stránok.
a2enmod userdir service apache2 restart
A zmeniť v /etc/apache2/mods-enabled/userdir.conf názov adresára z public_html na www Nakoniec už len reštart servera pomocou
service apache2 restart

Výsledkom bolo že sa systém lenny ugradoval na squeeze


15.11.2022 11:30 - 14:00 Uprade z verzie squeeze na wheezy

V /etc/apt/sources.list som opäť doplnil odkaz na distribúciu wheezy a predoslý zapoznámkoval.
deb http://archive.debian.org/debian wheezy main contrib non-free

Nasledne som aktualizovoal zoznam balíkov a urobil základný upgrade. A nakoniec aj kompletný upgrade na nové distro

apt-get update apt-get upgrade apt-get dist-upgrade

Po reštarte systém nabehol a tak som pozrel aký posledný kernel je k dispozícii pomocou

apt-cache search linux-source
Ten som potom stiahol s klasickým postupom rozbalil nakonfiguroval skompiloval a nainstaloval
apt-get install linux-source-3.2 cd /usr/src tar xjf linux-source--3.2.tar.bz2 cd linux-source-3.2 make menuconfig make-kpkg clean fakeroot make-kpkg --initrd --revision=1.0 kernel_image dpkg -i ../linux-image-3.2.78_1.0_i386.deb

Problémy nastali dva. Pri kompilácii už som vo voľbe --revision nemohol použiť slovo custom ale iba číslo revízie. Najväčší problém ale vyskočil pri inštalácii. Skončila chybou že na disku nie je žiadne volné miesto. Tak som zmazal staré zdrojové súbory pre hodne staré kernely. Lenže neuvolnilo sa vôbec nič. Nakoniec som zistil že /boot je mountované ako zvláštna partícia disku. Tak som vymazal staré a už nefunkčné bootovanie súbory predošlých jadier. Tým sa miesto vytvorilo a insštalácia už zbehla. Potom už som len pridal ďalšiu bootovaciu možnosť s kernelom 3.2 a reštartoval systém.

Opäť sa nedalo po sieti nikam dostať. Tektoraz to mal na svedomí bind9 démon. Tento sa tam nainštaľoval ako nový v tejto distribúcii a zrejme nie je dobre nakonfigurovaný. Nechcelo sa mi to zatiaľ riešiť a tak som iba pridal ďalší name server do /etc/resolv.conf. Takže podoba súboru je teraz takáto

search spsest.sk nameserver 127.0.0.1 nameserver 10.3.56.9
Celkom sa mi toto riešenie aj pozdáva takže vo finále ten lokálny asi zruším alebo ho nastavím ako sekundárny. Pretože 10.3.56.9 je nameserver školy a myslím že by tomohlo generovať menej sieťovej prevádzky.

Zároveň som dostal informáciu o riaditeľa že ISP opravil DNS pre doménu spsest.sk. Táto oprava mala riešiť problém s odosielaním mailov na niektoré nedôverčivé servery ako napr. gmail.com Tu sa ukázal problém s MTA. Aktuálne sa používa postfix. Pri jeho štarte ale vybehla opakovane to isté varovanie. Varovanie znelo

/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: program_directory=/usr/lib/postfix
Skúsil som aj rekonfigurovať postfix pomocou.
dpkg-reconfigure postfix
Ale výsledok bol rovnaký. Mail fungoval iba jednosmerne. Teda prijíma maily a doručuje lokálnym užívateľom. Ale neodosiela maily užívateľov von. A tak som nedokázal overiť či konfigurácia DNS je už v poriadku alebo nie.

16.11.2022 20:00 - 21:00 pokus o nápravu odosielania mailov

Pripojil som sa z domu a pokúsil som sa o nápravu problému s odosielaním mailov. V prvom rade som pozrel čo s tou chybou konfigurácie. Tu riešia podobnú chybu a je tu fajn odkaz na kompletné aktuálne platné konfiguračné parametre pre postfix Žiadný taký parameter program_directory tam teraz nieje tak som ho zapoznamkoval reštartoval postfix a je pokoj.
service postfix restart [ ok ] Stopping Postfix Mail Transport Agent: postfix. [ ok ] Starting Postfix Mail Transport Agent: postfix.
Následný test odoslania mailu ale dopadol opäť neúspešne.

Tak som začal hladať ako riešiť neodosielanie mailov. Tu sa rieši presne tento problém. Navrhuje sa tam preskúmať logy

/var/log/mail.log /var/log/mail.err /var/log/daemon.log
S preklapením som zistil že server neloguje od 15.11.22 11:45 kedy som rozbehol novú distribúciu. Ešte som skúsil pozrieť mailovú frontu pomocou.
mailq
To signalizuje že maily sú vo fronte a čakajú na spracovanie. Ale pokus o odoslanie nič neurobil.
sendmail -q

17.11.2022 20:00 - 21:30 druhý pokus o nápravu odosielania mailov

Prvé čo som sa rozhodol vyriešiť je absencia logovania. Na starých verziach debianu sa o logovanie staral sysklogd. Ten nevyzeral funčný. Chvíľa hľadania a tu sa rieši prese ten istý problém Takže
apt-get install inetutils-syslogd
A je vyriešené, logy už zase veselo bežia. Teraz už to loguje aj nejaké problémy do príslušných súborov ohľadov mailov. Zvyšok času píšem dokumentáciu.

Mail je už rozbehaný ale nemal som silu to popisovať. V podstate problém robila nejaká polovičatá konfigurácia z roznych verzií. Keď som sa dopracoval až na verziu Debian 11 s vykodil z konfiguračných súborov nejaké staré už nepodoporované voľby tak to začalo chodiť. Este to má nejaké muchy ale už sa to dá dokonca som nainštaloval aj web klienta Roundcube


3.2.2023 12:30 - 14:30 rozbehanie nových iptables

Podľa hesla pokrok nezastavíš sa zmenil balik iptables na nft. Samozrejme je tam nová syntax a tak podobne. Oveľa väčší problém je ten že v stave akom to mám tak to nefungovalo vôbec. Opäť bolo treba prekompilovať kernel a povoliť až ani neviem čo. Výsledkom toho je že som sa posunul o milimeter príkaz nft už zbehne ale výsledok je takýto
nft add table nat Error: Could not process rule: Address family not supported by protocol add table nat ^^^^^^^^^^^^^^
Na virtuálke to samozrejme funguje, lenže tam sa automaticky naťahujú potrebné moduly a navyše je tam novšie jadro. ja teraz jazdím 4.9.320 a aktuálna distribúcia beží na 5.10.0 Myslím si že toho mám v jadre povolené možno aj všetko, tak ako prvé sa posuniem na aktuálne jadro. A tu hneď problém nové jadro je zabalené inak ako staré takže ich treba rozbaliť pomocou
tar -xf linux-source-5.10.tar.xz
A za tým ďalšie prekvapenie a to že došlo miesto na disku. Nie je sa čo čudovať. Momentálne koreň súborového systému sídli na 9GB SCSI disku. Ešte je tam jeden taký istý disk. Kedysi pracovali tieto disky ako RAID0. Kompililácia kernelu je nateraz pozastavená i idem presúvať niečo niekam.

6.2.2023 14:30 - 15:30 vyprazdnenie disku /dev/sda3

Tento disk sa montuje ako roreň súborového systému. pomocou príkazu
du -d 1 -b
som si zistil čo koľko zaberá. Ukázalo sa že vhodný kandidát na odsun je adresár /usr , ktorý zaberá cez 3GB.

Ďalšie googlenie ukázalo že na kopírovanie celého stromu so zachovaním nastavenia užívateľov a práv by mohol stačit príkaz cp

cp -urp /usr /newscsi
jednotlivé voľby
u - po kopírovaní nastaviť vlastníka a skupinu
p - skopírovať aj práva
r - rekurzívne kopírovanie
Kopírovanie trvalo asi tak 20minút. Potom som premenoval /usr na /usrorig a vyrobil symbolický link tak aby /usr ukazoval na /newscsi/usr
mv /usr /usrorig
ln -s /newscsii/usr /usr
reboot
Po reštarte nemilé prekvapenie.
kernel panic
Ukázalo sa že odsunúť celý /usr z koreňového file systému nebol dobrý nápad. Je to preto že tento adresár obsahuje aj podadresár /urs/lib kde sú dynamicky načítavané knižnice a tieto treba načítať v čase keď je pripojený len koreňový FS. Och zase som sa niečo naučil a zaplatil som za to niekoľkými hodinami svojho života. Bolo treba zase rozobrať server pripojiť tam funkčnú CD-ROM, nabootovať inštalačné CD debianu (server nemá USB porty - 20rokov stará mašina) Potom spustiť rescue mód, vymazať link a premenovať odložený /usrorig späť. Potom reštart a fungujeme ako predtým. Takže zabité tri hodiny a výsledok nikde.

6.2.2023 14:00 - 15:00 vyprazdnenie disku /dev/sda3 druhý pokus

Na zaklade tragickej chyby, som teda zmenil ambície a rozhodol som sa odložiť iba /usr/src Tento adresár aktuálne zaberá asi 1GB a hlavne nové zdrojáky kernelu sa tiež inštalujú sem. Teraz už to išlo ako pomasle. Skoprírovane som už mal, tak som len vymazal nepotrebné adresáre ktoré zostali na pôvodnom disku
mv /usr/src /usr/srcorig
ln -s /newscsii/usr/src /usr/src
reboot
A hurá, systém nabehol, konfigurácia jadra fungovala. Už len zmazať /usr/srcorig a +1GB volného miesta a zároveň pri stiahnutí nového kernelu to už ide na druhý disk takže z koreňového to neodoberá.

7.2.2023 14:00 - 14:45 návrat k rozbehaniu nft

Opäť som chcel nainštalovať balik linux-source-5.10 lenže apt si tvrdilo že je už nainstalovaný. Že som ho ja manuálne zmazal mu vôbec nevadilo. Opäť nejaké to googlenie a výsledok
apt --reinstall install linux-source-5.10
Toto mu nanúti že to má nainštalovať znova. Teraz už zase známe príkazy, rozbaliť nakonfigurovať a preložiť. Konfiguráciu som nemenil uvidím či sa to polepší len vďaka novému jadru alebo bude treba zapínať nejaké nové voľby. Kompilácia spustená na konzole a zajra ráno uvidím čo urobí nové jadro.

Ďalšia vec čo mi tu stále vyskakuje je že ak sa spustí čokolvek z balika tak to píše takéto chyby

perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_MESSAGES = "POSIX", LANG = "sk_SK" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").

Skúsil som nasledovné ťahy
apt install locales #nic sa nestalo apt --reinstall install locales #preinstalovalo aj vygenerovalo sk_SK.UTF-8... nove ale nepomohlo update-locale #skoncilo s varovaniami a nic sa nezmenilo dpkg-reconfigure locales
Toto posledné zabralo lebo ma napadlo zapnúť nielen UTF8 ale aj sk_SK ISO-8859-2. Potom tie otravné hlášky zmizli. Ak som to vrátil na pôvodné iba UTF-8 tak sa znova objavili. Povolil som teda obe sk možnosti a zdá sa že je pokoj. Aj keď sa mi to moc nepáči lebo to vyzerá že je to nastavneé na sk_SK a nie na sk_SK.UTF-8.

Horšie je že sa zdá že kompilácia opäť zostala visieť ako keď som sa to pokúšal skompilovať z domu. Na dnes stačilo. Pozriem či to do rána nepohne potom budem snoriť ďalej.

Pozrel som sa večer z domu a kompilácia stála tam kde bola keď som odchádzal zo školy. Zabil som posledný spustený proces a potom tuším ešte jeden. Následne sa už spistilo kompilovanie jadra lebo som videl procesy s menom gcc. Ráno keď som prišiel tak ma čakalo skompilované jadro zabalené v pkg.

inštalácia jadra varovala že nie je skompilovaný modul ovládača pre sieťovú kartu e100. Skontroloval som a zistil som že mám sieťovkové drivery kompilované do jadra. Tak som aktualizoval grub a reštartoval stroj

dpkg -i linux-image-5.10.162_1.0_i386.deb #instalacia jadra update-grub reboot

Po reštarte som ako prvé skúsil či žije sieťové rozhranie a fungovalo. Kupodivu ping začal vypisovať rovnakú chybu ako nft.

ping 10.3.56.9 ping: socket: Address family not supported by protocol PING 10.3.56.9 (10.3.56.9) 56(84) bytes of data. 64 bytes from 10.3.56.9: icmp_seq=1 ttl=64 time=0.303 ms 64 bytes from 10.3.56.9: icmp_seq=2 ttl=64 time=0.203 ms 64 bytes from 10.3.56.9: icmp_seq=3 ttl=64 time=0.262 ms ^C --- 10.3.56.9 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2028ms rtt min/avg/max/mdev = 0.203/0.256/0.303/0.041 ms
Ale fungoval. Takže došlo na očakávaný netfilter nft
nft add table nat
A hurá. žiadne protesty, ani to nepíplo. Overenie či to aj niečo vykonalo
nft list tables table ip nat
Zdá sa že to funguje.

9.2.2023 14:00 - 11:15 opäť kompilovanie kernelu

Zdanie sa ukázalo klamlivé. Vytvoriť nf tabuľku sa síce dá ale to je všetko. Vytvoriť chain a nastaviť tam pravidlá opäť skončí s chybou. Tak som opäť spustil konfiguráciu kernelu a tentoraz som zapol všetko čo len trochu pripomínalo NFT.

problémom sa ukázala kompilácia. Stále to zostávalo viseť ani finta s kill príkazom nezaberala. Gogglenie ukázalo že tietyo nové kernely sa kompilujú iným postupom

make nconfig make clean make bindeb-pkg
Toto už pekne kompiluje jadro a už to tam nevypisuje ani žiadne chyby ohľadom locale. Pokrok nezastavíš. Kompilovalo to pekne ale výsledok nepotešil. Kompilovalo to totiž na amd64 architektúru. Bolo treba pustiť konfiguráciu a nastaviť tam typ procesora ktorý je v tomto prípade Pentium III. Kompilácia spustená a keže to trvalo asi dve hodiny tak, idem domov a ráno sa uvidí.

10.2.2023 07:30 - 14:45 opäť kompilovanie kernelu

Včerajsí kernel opäť nedovoľuje pridat nat veci. Ale už mi ušlo pridať input pravidlo. Znova som snoril net a našiel že treba skontrolovať CONFIG_IP_NF_NAT A teraz to pekné nové čo som našiel. Nový konfigurátor kernelu má špéci funkciu F8SymSearch Potom tam stačí napísať IP_NF_NAT a okamžite vidím že je to nepovolené a navyše vidieť aj kde a čo všetko preba povoliť. Ako nájsť nejakú zakuklenú voľbu kernela

Potom je už ľahké vliesť do príslušnej sekcie a povoliť čo treba. Navyše to vie násť všetky voľby čo obsahujú NFT alebo NAT. Dobrý pokrok jaderní programátori.

Toto je tá voľba čo chýbala

Nasleduje obvyklé kolečko kompilácie, tá už ale trvá krátko nakoľko drtivá väčšina jadra je už skompilovaná. instalácia jadra z vygenerovaného balíka. Update zavádzača grub. A jeto. Konečne je nádej že NAT cez nf tables by mohlo fungovať.

9.2.2023 11:15 - 11:15 routovanie vnútornej siete von do sveta

postupojem podľa tohoto návodu Configuring NAT using nftables Začínam tou podľa mňa jednoduchšou cestou čo je maškaráda. Je to vraj pomalšie ale pravidlá sú jednoduchšie.
nft add table nat nft -- add chain nat prerouting { type nat hook prerouting priority -100 \; } nft add chain nat postrouting { type nat hook postrouting priority 100 \; } nft add rule nat postrouting oifname "eth1" masquerade

Všetko to zbehlo hlatko. Tak štartujem na vnútornej sieti windows nastavujem default gw na ip adresu servera 192.168.30.252 Testujem prístup k DNS pomocou

ping 10.3.56.9
a nič. Ale ešte si pamätám že na servery treba povoliť forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward ping 10.3.56.9
A už to šrotuje. Púšťam prehliadač skúšam nejakú stránku. Stránka sa zobrazí. Hurá, ďalší bod pesničky je hotový

Trvalé aktivovanie IPv4 forwardingu. V súbore /etc/sysctl.conf treba povoliť (odpoznámkovať) net.ipv4.ip_forward=1 Kompletný popis Ako nastaviť IPv4 forwarding

13.2.2023 14:00 - 14:45 Podozrivý UDP port

Dnes som si pozrel aké sú na serveri otvorené porty. Začínam mať podozrenie že by mohol spôsobovať problém s prihlasovaním do domény na počítačoch v učebni 906. Zatiaľ som urobil jeden pokus keď sa štyria žiaci nevedeli prihlásiť do domény. Po odpojení vnútornej sieťovej karty s adresou 192.168.30.252 sa po reštarte už prihlásiť mohli. Zatiaľ to nepovažujem za celkom potvrdené ale idem po tejto stope. Príkazom netstat -l som si vypísal otvorené porty a sokety. Z výpisu ma zaujal jeden ktorý netuším prečo tam je. Ide o UDP protokol na porte 52284. Zvlášne je že počúva na všetkých IP adresách.
netstat -l udp 0 0 0.0.0.0:52284 0.0.0.0:*
Takže ma začalo hodne zaujímať čo tam počúva za proces a prečo. Malá úprava príkazu a dozviem sa aj meno procesu ktorý to má na svedomí
netstat -lp udp 0 0 0.0.0.0:52284 0.0.0.0:* 1807/avahi-daemon:

Internet hovorí že tento proces slúži na broadcastovanie jeho IP adresy v lokalnej sieti, kde napríklad informuje o tom že poskytuje zdielanú tlač. Z tohoto sa javí že je to vec absolútne nepotrebná a idem tu teda zrušiť. Najprv sa teda pozriem čo to momentálne robí. Potom to deaktvujem aby sa to už nespúšťalo a tiež to stopnem aby to nebežalo

systemctl status avahi-daemon systemctl disable avahi-daemon systemctl stop avahi-daemon
Divné otvorené porty zmizli a teraz budem sledovať či to bude mať nejaký dopad na chod učebne alebo nie.

17.2.2023 9:30 - 10:30 inštalácia a nastavenie DHCP

Včera mi správca siete vypnul DHCP pre môj segment siete 192.168.30.0/24 Užívateľské počítače a servery už sú prestavené na statické IP adresy, ale ešte používam virtualne počítače a tam potrebujem priraďovať adresy dynamicky. Potrebujem si nainštalovať DHCP server tak aby počúval len na rozhraní eth0 A tiež potrebujem aby sa to dalo jednoducho vypnúť a zapnúť. Nakoľko si žiaci budú stavať spoje DHCP servery a budú overovať ich funkčnosť. Postupujem podľa návodu How To Install DHCP Server in Ubuntu & Debian Tu je komplet dokumentácia isc-dhcp-44-manual-pages-dhcpd

apt install isc-dhcp-server mcedit /etc/default/isc-dhcp-server # zmeniť na INTERFACESv4="eth0" mcedit

4.7.2023 9:30 - 11:30 inštalácia a nastavenie TFTP servera

Po nedavnom update mi stále blbla inštalácia balíka linux-image-5.10.162 Zistil som konečne ako to odstrániť. Prvý príkaz sa to snažil dokončiť. Nasledovný odstránil inkriminovaný balík Nasledne blbol ešte jeden takže aj ten išiel preč. A nakoniec som odstránil všetko zbytočné
apt-get -f install apt-get remove --purge linux-image-5.10.162 apt-get remove --purge initramfs-tools apt-get autoremove
Po tomto sa konečne môže ísť na vec. Zistil som že pre ukladanie konfigurácií cisco zariadení budem potrebovať TFTP server. ako prvý som nainštaloval nejaký čo sa spúštal pomocou inet demona. Tam som ale nevedel nastaviť aby bolo možné konfiguráciu aj ukladať Tak som nanainštaloval tftpd-hpa Ten sa ale odmietol spustiť nakoľko nenašiel IPv6 socket. Našiel som že treba pridať voľbu -4 a --create. Potom sa už spustil, ale nechcel zapisovať súbory. Bolo treba upraviť konfiguráciu a nastaviť vlastníka cieľového adresára na užívateľa tftp Nakoniec ešte nastaviť adresu aby to žilo len na lokálnej sieti
apt install tftpd-hpa mcedit /etc/default/tftpd-hpa TFTP_USERNAME="tftp" TFTP_DIRECTORY="/srv/tftp" TFTP_ADDRESS="192.168.30.252:69" TFTP_OPTIONS="-4 --secure --create" chown tftp. /srv/tftp