Re: Více správců serveru - delegace root práv
> Dan Lukes wrote: > >> Zkoušel jsem příkaz su - přidal jsem daného uživatele do skupiny wheel. >> Ovšem pokud uživatel použije su, vyzve ho to k zadání hesla, ovšem ne svého >> hesla, ale hesla roota, což mě nepomůže. > > su ma parametr - jmeno uzivatele, na ktereho se chceme prepnout. Ano, > bez parametru to znamena uzivatele "root", ale na toho se on prepinat > nechce - to eni "jeho" superuzivatel. On musi 'su' volat se jmenem toho > superuzivatele, ktery byl pro nej vytvoren (je jedno, jak se takovy > superuzivatel bude jmenovat, on ho jen musi znat a za to 'su' napsat). > > 'su' ho pak vyzve k zadani hesla toho uzivatele. > > Heslo superuzivatele root on znat nebude, a ty nebudes znat heslo "jeho" > superuzivatele. Tu by bolo vhodne este doplnit, ze je mozne mat viacej zaznamov v master.passwd s rovnakym user id. Teda aj viacej uzivatelov s uid 0 (root). Casto byva taky superuzivatel napriklad toor (root pospatku). Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Pomaly zapis na SSD
Zdravim, mam dva podobne servery a na jednom sa nam vyskytol problem s performance pri zapise. Problem sa prejavuje napriklad pri zapise do databaze (MySQL, InnoDB). Relativne nenarocny insert do “logovacej" tabulky trva cez jednu sekundu. Ale nebude to suvisiet s databazou, pretoze problem to robi i inde. Napriklad time make deinstall postfix na zdravom serveri: root@portbuild:/usr/ports/mail/postfix # time make deinstall ===> Deinstalling for postfix … 0.060u 0.048s 0:00.17 58.8% 3699+3714k 58+624io 15pf+0w a na pomalom serveri: root@portbuild:/usr/ports/mail/postfix # time make deinstall ===> Deinstalling for postfix … 0.047u 0.063s 0:27.22 0.3% 3159+2964k 13+593io 17pf+0w … teda o 27 sekund viacej. Pouzivame ZFS na SSD. Trim je zapnuty. Read performance vyzera byt ok (diskinfo -tv /dev/ada2 zobrazuje podobne hodnoty ako pri instalacii pred 2 rokmi). Zapis 500 MB trva na oboch serveroch rovnaky cas (5.4 sekundy): # time dd if=/dev/random of=/tmp/blaf bs=1024000 count=500 500+0 records in 500+0 records out 51200 bytes transferred in 5.408680 secs (94662654 bytes/sec) 0.000u 5.406s 0:05.40 100.0%25+2744k 1+938io 0pf+0w Servery sa lisia v diskoch, pomaly ma 2x Crucial M4 128 MB , zdravy ma 2x Samsung 840 PRO . Na co by som sa mal poziet? Dakujem za rady, Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Pomaly zapis na SSD
> Dan Lukes wrote: > >> mam dva podobne servery a na jednom sa nam vyskytol problem s performance >> pri zapise. > > Sekvencni zapis 1/2GB v blocich velikosti 1000kB je o dost jine > zatizeni, nez zapis podobneho mnozstvi dat v po 4kB blocich nahodne po > disku. Chapem. Naviac neviem ako to funguje interne, ci ten sekvencny zapis 500 MB nebol nahodou asynchronny iba do RAM. > >> Servery sa lisia v diskoch, pomaly ma 2x Crucial M4 128 MB > 040H>, zdravy ma 2x Samsung 840 PRO . > > Disky mohou mit jinou vnitrni geometrii. Pri instalacii som zarovnaval na 4k bloky. Tak to by snad malo byt ok. I ked je zaujimave, ze jeden disk z mirroru zobrazuje nejake nenulove hodnoty v Non4k_Aligned_Access a druhy nulove: ada2: 181 Non4k_Aligned_Access0x0022 100 100 001Old_age Always - 3 0 3 ada3: 181 Non4k_Aligned_Access0x0022 100 100 001Old_age Always - 0 0 0 Ale mozno to bolo este pri instalacii. > U disku zaplnenych nebo blizko zaplneni pak bude hrat roli zda ma > fyzicky disk over-provisioning. Disk uz bol dost plny, zostavalo 8 GB. Po zmazani snapshotov som sa dostal na 30 GB, ale rychlosti to nepomohlo. # zfs list ssd NAME USED AVAIL REFER MOUNTPOINT ssd 71.5G 30.4G 144K none Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Pomaly zapis na SSD
> On Robert Vojcik wrote: > > http://www.vojcik.net/samsung-ssd-840-pro-performance-degradation/ > > Tuna som zas robil pred dlhsim casom uz test samsungu, mozes omrknut > aspon SMART hodnoty ktore sa ako menili a pozriet sa ako su na tom tvoje > disky. Pozrel som na tie smart hodnoty a vidim toto: Device Model: M4-CT128M4SSD1 Firmware Version: 040H SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 100 100 050Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0033 100 100 010Pre-fail Always - 0 9 Power_On_Hours 0x0032 100 100 001Old_age Always - 16880 12 Power_Cycle_Count 0x0032 100 100 001Old_age Always - 39 170 Grown_Failing_Block_Ct 0x0033 100 100 010Pre-fail Always - 0 171 Program_Fail_Count 0x0032 100 100 001Old_age Always - 0 172 Erase_Fail_Count0x0032 100 100 001Old_age Always - 0 173 Wear_Leveling_Count 0x0033 181 181 010Pre-fail Always - 5277 174 Unexpect_Power_Loss_Ct 0x0032 100 100 001Old_age Always - 35 181 Non4k_Aligned_Access0x0022 100 100 001Old_age Always - 3 0 3 183 SATA_Iface_Downshift0x0032 100 100 001Old_age Always - 0 184 End-to-End_Error0x0033 100 100 050Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 001Old_age Always - 0 188 Command_Timeout 0x0032 100 100 001Old_age Always - 0 189 Factory_Bad_Block_Ct0x000e 100 100 001Old_age Always - 86 194 Temperature_Celsius 0x0022 100 100 000Old_age Always - 0 195 Hardware_ECC_Recovered 0x003a 100 100 001Old_age Always - 0 196 Reallocated_Event_Count 0x0032 100 100 001Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 001Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 001Old_age Offline - 0 199 UDMA_CRC_Error_Count0x0032 100 100 001Old_age Always - 0 202 Perc_Rated_Life_Used0x0018 181 181 001Old_age Offline - 175 206 Write_Error_Rate0x000e 100 100 001Old_age Always - 0 Nie som si isty, ale citam to spravne, ze disk je “po svojej zivnostnosti” na 175% (Perc_Rated_Life_Used)? A Wear_Leveling_Count 5277 je asi tiez velmi vysoka hodnota, ze? Druhy disk ma podobne hodnoty. Zaver je teda, ze je potreba vymenit disk? Disk z druheho serveru: Device Model: Samsung SSD 840 PRO Series Firmware Version: DXM05B0Q SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010Pre-fail Always - 0 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 10921 12 Power_Cycle_Count 0x0032 099 099 000Old_age Always - 38 177 Wear_Leveling_Count 0x0013 091 091 000Pre-fail Always - 293 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010Pre-fail Always - 0 187 Uncorrectable_Error_Cnt 0x0032 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 068 064 000Old_age Always - 32 195 ECC_Error_Rate 0x001a 200 200 000Old_age Always - 0 199 CRC_Error_Count 0x003e 100 100 000Old_age Always - 0 235 POR_Recovery_Count 0x0012 099 099 000Old_age Always - 8 241 Total_LBAs_Written 0x0032 099 099 000Old_age Always - 65876529478 Tento snad vyzera ok. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Pomaly zapis na SSD
> On 9. 6. 2015, at 10:50, Dan Lukes wrote: > > Robert Vojcik wrote: >> My sme v par pripadoch museli pristupit k "refreshu" disku. Proste >> vytiahnes disk z raidu, prepises ho nulami, zalozis spat, vytiahnes, >> druhy, prepises nulami zalozis spat a mas na cas pokoj. > > Pokud pak nedas "erase" tak skoncis s diskem, kterej si o sobe mysli, ze > je naprosto plnej. > > Byt' nemohu zcela vyloucit, ze konkretni disk s konkretnim firmwarem > povazuje zapis sektoru se samymi nulami efektivne za "trim" ... “Refresh” disku by som mohol skusit. Ako sa dava ten “erase”? Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Jak na logovani systemu (auth, messages...) a sluzeb (apache, proftpd...) pri loadbalancingu?
> On 15. 10. 2015, at 21:55, Gabriel wrote: > > jak resite logovani napr. apache pri loadbalancingu 2 a vice serveru? Logujeme na kazdom serveri zvlast. Statistiky navstevnosti generujeme raz denne na “backup” serveri, na ktory sa posielaju zalohy z kazdeho serveru pomocou zfs send. Na backup serveri je jail, ktory ma k logom read-only pristup (bud zfs mountpoint alebo nullfs mount) a tam bezi skript, ktory tie logy zlucuje do jedneho vystupu (konkretne logresolvemerge.pl z awstats). Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: ZFS snapshot - replikace prirustkovych snapshotu
Jan Dušátko wrote: > Uz nejakou dobu se snazim resit inkrementalni kopie ZFS > snapshotu na zalozni server, bohuzel vzdy se mi zacne kopirovat > kompletni volume nebo dataset. Hledam zpusob, jak zajisti kopirovani jen > a pouze daneho snapshotu a minimalizovat prenosy. Snapshotom myslis snapshot jedneho filesystemu, alebo rekurzivny snapshot? V pripade, ze NEriesis rekurzivny snapshot, tak najjednoduchsie je urobit pociatocnu plnu zalohu takto: zfs send pool/path@daily_2015-11-26 | ssh backup zfs receive pool2/path2@2015-11-26 (intermediary filesystemy u path2 musia existovat, cielovy filesystem nesmie) a dalej inkrementalne zalohy takto: zfs send @daily_2015-11-26 pool/path@daily_2015-11-27 | ssh backup zfs receive pool2/path2@2015-11-27 V pripade, ze chces mat snapshot pomenovany rovnako na zaloznom serveri, tak nemusis uvadzat nazov snapshotu u zfs receive. V ukazke som ich rozlisil (daily_2015-11-27 vs 2015-11-27). Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: ZFS snapshot - replikace prirustkovych snapshotu
Jan Dušátko wrote: > jde mi o nasledujici. > mam zfspool POOL a v nem treba 10 volumu VOL1, VOL2... VOL10 > 1) Na zacatku udelam snapshot celeho souboroveho systemu > 2) Denne delam snapshoty pres cely pool (udela i volume) > 3) Chci prenest jenom rozdilova data na zalozni server, ktery nedela > nic, jen ceka Princip je teda jednoduchy: 1) Na zaciatku urobit plnu zalohu 2) Denne urobit inkrementalnu zalohu medzi vcerajsim snapshotom a dnesnym snapshotom Trosku ma metu tie volumy. V terminologii ZFS je volume block device. Napriklad volume pre swap. Ale nikdy som ich nepouzil. Tak neviem, ci myslis block device, alebo obycajny filesystem. Ale z pohladu zalohovania by to malo byt jedno. > Zkousel jsem (pro zkopirovani posledniho existujiciho snapshotu) > /sbin/zfs send -Rv `/sbin/zfs list -t snapshot | /usr/bin/grep > "/POOL@VOL" | /usr/bin/cut -f1 | /usr/bin/cut -d " " -f1 | /usr/bin/tail > -n 1` > /backup/zfs/zfsdata.pool Chapem spravne, ze to ma zalohovat posledny snapshot *jedneho* volume/filesystemu? Trosku ma metie to “/POOL@VOL”… cakal by som “POOL/VOL”. Ten zapis v backticks by sa dal skratit na: zfs list -r -t snapshot -H -o name POOL/VOL | tail -n 1 -H - scripting mode (tabulatory namiesto medzier a bez hlavicky) -o - vypisuje iba menovane property Teraz su tri moznosti ako zalohovat, ktore ma napadaju a mam vyskusane: 1) Jednoduche zalohovanie, ako som popisoval predtym. Na zaciatku sa pouzije jednoduche `zfs send snapshot` a potom inkrementalne `zfs send -i snapshot1 snapshot2`. Pozeram, ze predtym som tam mal chybu, vypadlo mi to -i: zfs send pool/path@daily_2015-11-26 | ssh backup zfs receive pool2/path2 zfs send -i @daily_2015-11-26 pool/path@daily_2015-11-27 | ssh backup zfs receive pool2/path2 alebo zfs send pool/path@daily_2015-11-26 | ssh backup zfs receive pool2/path2@2015-11-26 zfs send -i @daily_2015-11-26 pool/path@daily_2015-11-27 | ssh backup zfs receive pool2/path2@2015-11-27 2) Zalohovat “rekurzivne” pomocou -R. Inkrementalne potom pomocou -R -I. To zalohuje vsetky descendant file systems - vsetky snapshoty, clones, rekurzivne pod-filesystemy a dokonca i properties. Pri prijimani je vhodne potom mat prepinac -u, aby sa automaticky nenamontovali prenasane filesystemy, pretoze sa prenasaju i properties a teda i mountpoint a ked sa takto zalohuje /, alebo /usr, tak to potom konci vytuhnutim systemu. -I zabezpeci, ze sa zalohuju i intermediary snapshots. zfs send -R pool/path@daily_2015-11-26 | ssh backup zfs receive pool2/path2 zfs send -R -I @daily_2015-11-26 pool/path@daily_2015-11-27 | ssh backup zfs receive -u pool2/path2 Obcas je v takomto pripade potreba pouzit u zfs receive prepinac -F. Ten robi rollback filesystemu na posledny snapshot, takze ked je zaloha namontovana a zmeni sa, tak to revertne. Treba si davat pozor, ze -F okrem toho maze vsetky snapshoty u zalohy, ktore neexistuju u zdroja. Takto je mozne ziskat identicke kopie filesystemov (rekurzivne) do posledneho snapshotu - napriklad sa tak da zalohovat cely pool. Mne sa na tom nepaci to, ze ked by mi nieco zmazalo vsetky snapshoty, tak sa zmazu i zo zalohy, takze to -F nepouzivam. 3) Zalohovat “rekurzivne" pomocou -R, ale inkrementalne zalohy pomocou -R -i (obdoba 2), ale -i namiesto -I). Funguje to rovnako, ale neposielaju sa intermediary snapshoty. zfs send -R pool/path@daily_2015-11-26 | ssh backup zfs receive pool2/path2 zfs send -R -i @daily_2015-11-26 pool/path@daily_2015-11-27 | ssh backup zfs receive -u pool2/path2 Takto to robim ja. Na zdroji robim hodinove, denne aj mesacne zalohy. Na backup prenasam iba denne zalohy. Keby som pouzil -I, tak sa mi budu prenasat i hodinove. Na backupe si potom mazem snapshoty, ako potrebujem. Napriklad po uvodom skopirovani je mozne vsetky snapshoty okrem posledneho zmazat. > Bohuzel se mi prenasel vzdy cely volume. Cele sa to musi preniest uplne na zaciatku. Potom zfs send -i alebo -I prenasa uz iba inkrementalne. > Pokud jsem dal zfs send a zfs receive, zarvalo mi to na nejake chyby. Je jedno, ci sa urobi zfs send do suboru a receive potom zvlast zfs receive z toho suboru, alebo naraz zfs send | zfs receive. > Moje idea byla v hodinovych intervalech prenaset rozdily pro pripad > necekane situace. Cilem je mit naprosto identicke prostory. Naprosto identicke prostory je najlepsie pomocou toho `zfs send -R -I | zfs receive -F` v pripade, ze nevadi necekana situace, ze niekto zmaze stare snapshoty. No a na zaver este poznamka, ze ZFS je zlozite a moze sa teoreticky stat, ze vo filesysteme vznikne chyba, ktora sa pomocou zfs send | zfs receive prenesie aj na backup… v najhorsom pripade clovek zostane s nenamountovatenymi filesystemami aj na backupe. Zatial sa mi to nestalo. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: dns-terror (fastresolve-2.10_5) core dump na FreeBSD 10.x
Dan Lukes wrote: >> Jak te znam, pouzivas na to svoje reseni :) > > Ten to na strane klientu delam jak kreten v podstate rucne. > > Nejdriv musim overit, ze na stroji nahodou neni nejaky balicek, ktery neni k > dispozici prelozeny v repository. Protoze takovy pkgng tise ignoruje a kdyz > si ho nenajsdes sam, mas smulu. > > Pak si necham ukazat co chce pkgng delat pokusim se uhadnout, jestli je to > rozumny, nebo je to nektery z uletu. No a pak ho to necham, nebo nenecham > udelat. Ja instalujem tak, ze preinstalujem vsetky balicky a zmazem uz nepotrebne zavyslosti: pkg upgrade -f pkg autoremove Nestava sa mi, ze by mi chybal nejaky balicek v repository, takze to neriesim. >> Ale vsem ostatnim muzu doporucit Poudriere. > > Oni maji za ohromnou vyhodu, ze vlastne kazdy balik kompiluji na cistym > prostredi. Me to naopak pripada jako nevyhoda. Ja ten port pak neprovozuju v > prostredi, kde je sam, ale v prostredi, kde jsou dalsi balicky. To som netusil. Myslel som, ze to Poudriere skusim, ale radsej zostanem u svojeho riesenia. > Takze kdyz jednou za cas proste vydam pokyn, at se prekompiluje vsech tech > cca 900 portu co potrebuju Akurat ja neaktualizujem pomocou portupgrade, ale zacinam z cisteho prostredia: zmazem vsetky nainstalovane balicky a nainstalujem tych 60 portov, co potrebujem, co so zavyslostami nainstaluje 400 balickov. (Myslim, ze som to zacal takto robit raz davno, ked mi portupgrade nieco rozbil so zavyslostami a takto nie som zavysli ani na spravnom fungovani portupgrade.) Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: balickovaci system (was: dns-terror)
Dan Lukes wrote: >> Ja instalujem tak, ze preinstalujem vsetky balicky a zmazem uz nepotrebne >> zavyslosti: >> >> pkg upgrade -f >> pkg autoremove > > Nevim jak to delas, ze ti to funguje, ale nez jsem na 'auto' uplne zanevrel, > se mi nekolikrat stalo, ze se 'auto' najednou objevilo u balicku, kde driv > (spravne) nebylo. No a pak mi ho 'autoremove' smazalo. Nestras. To sa mi este nestalo. Ale vystup z `pkg autoremove` zbezne kontrolujem, tak to by som si snad vsimol. Maximalne sa mi obcas stane, ze to zmaze nieco, co je potrebne, ale nie je uvedene ako zavislost (pardon predtym za hrubku). Napriklad sa pouzila nejaka kniznica, co bola pritomna pri preklade, ale (uz) nebola uvedena ako zavislost. Ale to je chyba v portoch, ten problem by nastal, aj keby som robil z takeho repozitory cistu instalaciu. Hmm… tu by pouzitie Poudriere bola asi vyhoda. > Zejmena v kombinaci s tou vlastnosti, ze na klientovi to ani necekne, kdyz v > repository neco chybi, se mi to jevi prilis nebezpecny a uplne jsem to > prestal pouzivat. To mi problem nerobi. Ked tak kontrolujem, ci pred/po upgrade nezostali v `pkg version` nejake otazniky. > Me 'kompletni preklad' trva tedka neco mezi triceti a ctyriceti hodinami. A > behem toho ten stroj takrka nekde pouzivat (ne kvuli vytizeni, ale proste ty > portu nejsou v konzistentnim stavu). To je na to co potrebuju az prilis > dlouho. Chapem, u mna to trva iba asi hodinu alebo dve. Ale mam na to vyhradeny jail, takze ho nepotrebujem pocas kompilacie na nic pouzivat. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Reštart pri zvýšenej záťaži
> Vladimír Drgoňa wrote: > > 16GB RAM, 2x3000GB WD RED > 2x3000GB mirror zfs > > Riešim to deduplikáciou Neviem ake mas zaplnenie disku, ale podla https://wiki.freebsd.org/ZFSTuningGuide je potreba az 5 GB na TB pri deduplikacii. > dáta zaberajú na disku menej ako polovicu oproti stavu pred jej zapnutím. IMHO za to deduplikacia nestoji - za tie problemy. Pouzivanie deduplikacie je pomalsie a potrebuje vela pamete. Dobre vysledky dava kompresia. Ta naopak moze byt aj rychlejsia. Ale tu predpokladam, ze uz pouzivas. > Keď vypnem dedup, server beží bez problémov aj rok. Ja som za vypnutie. Ked nestaci miesto, tak dokupit disky. V opacnom pripade navysit RAM. Mimochodom, na ZFS je viac ako vhodne pouzivat ECC RAM. V sucasnej situacii by mohlo pomoct aj nastavit zfs.arc_max na nejaku rozumnu hodnotu. Default je velkost RAM - 1GB… skusil by som nastavit na 2G a ked to pomoze, tak navysoval az na polovicu velkosti RAM. Skoda ze ZFS nema nejaku offline deduplikaciu. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: svn a kernel config
>> PS: IPSEC uz zadny ze zakazniku nepotrebuje > > IPSEC jsem mel za mrtvej uz kdyz jsem ho pred dvanacti nebo kolika lety > nasazoval poprvy. IPSEC nedavam do kernelu uz leta ;-) FYI, od FreeBSD 10.3 a 11.0 bude IPSEC v GENERIC: http://svnweb.freebsd.org/base?view=revision&revision=285142 Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Samovolne odpajanie disku
Zdravim, vymenil som v serveri SSD disky z Crucial na Samsung a jeden disk sa mi zacal samovolne odpajat a nasledne sa hned pripopoji: kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 kernel: ada1: s/n S251NXAG746575T detached kernel: (ada1:ahcich1:0:0:0): Periph destroyed kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 kernel: ada1: ATA-9 SATA 3.x device kernel: ada1: Serial Number S251NXAG746575T kernel: ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) kernel: ada1: Command Queueing enabled kernel: ada1: 244198MB (500118192 512 byte sectors: 16H 63S/T 16383C) kernel: ada1: Previously was known as ad6 Tieto hlasky su vsetky v jednej sekunde. Mam tam ZFS s mirroringom, takze dam `zpool online` a v momente sa to resilveruje. Ale za mesiac sa mi to stalo uz treti krat. Co by ste odporucali? Vymenit kabel? Zapojit do ineho portu? Je tam Samsung 850 PRO, Samsung 840 PRO a dva pevne disky WD. Robi to iba ten Samsung 850. Dakujem za rady, Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Samovolne odpajanie disku
On 5. 4. 2016 Miroslav Lachman wrote: > >> Co by ste odporucali? Vymenit kabel? Zapojit do ineho portu? >> >> Je tam Samsung 850 PRO, Samsung 840 PRO a dva pevne disky WD. Robi to iba >> ten Samsung 850. > > Tipnul bych si problem s napajenim, nebo kabel. Kazdopadne by ti v tomhle > mohlo pomoct taky zkoumani vystupu SMART (sysutils/smartmontools), jestli se > tam zvysuji hodnoty nejakych counteru atd. Tak som skoro po dvoch mesiacoch prehodil napajacie a SATA kabely medzi dvoma SSD a dvoma HDD, co tam su. Ale urobilo mi to znovu: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: s/n S251NXAG746575T detached (ada3:ahcich3:0:0:0): Periph destroyed ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ATA-9 SATA 3.x device ada3: Serial Number S251NXAG746575T ada3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada3: Command Queueing enabled ada3: 244198MB (500118192 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 Znovu to odpojilo ten Samsung 850 PRO, ako predtym. Mimochodom, za tu dobu skoro dvoch mesiacov ten disk odpojilo asi 7 krat. Data zo SMART vyzerajú ok: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010Pre-fail Always - 0 9 Power_On_Hours 0x0032 099 099 000Old_age Always - 1965 12 Power_Cycle_Count 0x0032 099 099 000Old_age Always - 15 177 Wear_Leveling_Count 0x0013 099 099 000Pre-fail Always - 11 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010Pre-fail Always - 0 187 Uncorrectable_Error_Cnt 0x0032 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 067 056 000Old_age Always - 33 195 ECC_Error_Rate 0x001a 200 200 000Old_age Always - 0 199 CRC_Error_Count 0x003e 100 100 000Old_age Always - 0 235 POR_Recovery_Count 0x0012 099 099 000Old_age Always - 4 241 Total_LBAs_Written 0x0032 099 099 000Old_age Always - 4707402871 Rovnaky disk (kupovany naraz) mam aj v inom serveri a tam su data zo SMART podobne (resp. horsie, je pouzivany dlhsie): ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 099 099 010Pre-fail Always - 1 9 Power_On_Hours 0x0032 098 098 000Old_age Always - 5492 12 Power_Cycle_Count 0x0032 099 099 000Old_age Always - 9 177 Wear_Leveling_Count 0x0013 098 098 000Pre-fail Always - 81 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 099 099 010Pre-fail Always - 1 181 Program_Fail_Cnt_Total 0x0032 100 100 010Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010Old_age Always - 0 183 Runtime_Bad_Block 0x0013 099 099 010Pre-fail Always - 1 187 Uncorrectable_Error_Cnt 0x0032 099 099 000Old_age Always - 13 190 Airflow_Temperature_Cel 0x0032 067 060 000Old_age Always - 33 195 ECC_Error_Rate 0x001a 199 199 000Old_age Always - 13 199 CRC_Error_Count 0x003e 100 100 000Old_age Always - 0 235 POR_Recovery_Count 0x0012 099 099 000Old_age Always - 3 241 Total_LBAs_Written 0x0032 099 099 000Old_age Always - 31085531082 Kedze to urobilo aj po vymene kabelov, tak predpokladam, ze chyba je v disku, alebo v kombinacii disku a serveru. Napada ma iba skusit prehodit tie disky navzajom medzi servermi. Alebo ma niekto este nejaky tip? Dakujem, Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: SSD pro bsd
> Miroslav Lachman wrote: > >> Jinak se mi velmi neosvedcil gmirror v souvislosti s SSD, nazory se na to >> ruzni, ale prevladaly, ze by se pouzivat nemel, mne se to take neosvedcilo. > > Co je s nim za problem? Nemam pocit, ze by zrovna gmirror udelal s tim SSD > neco jineho, nez jakykoliv jiny mirror, nebo zapisy primo na disk. Samsung > 840 Pro mi v gmirroru bezi pro MySQL databazovy server uz vic jak dva roky. Mozno tym myslel mirror vseobecne. SSD disky v mirroru budu rovnako zatazovane a mozno sa opotrebuju naraz. Mam taku osobnu skusenost, dva SSD disky (Crucial m4) v ZFS mirrore. Smartd zacal hlasit, ze jeden z diskov umiera: Device: /dev/ada2, FAILED SMART self-check. BACK UP DATA NOW! Device: /dev/ada2, Failed SMART usage Attribute: 173 Wear_Leveling_Count. Tak som ten disk vymenil za Samsung 850 Pro, ale pocas resilveringu sa ukazalo, ze aj ten druhy disk z mirroru uz nie je v najlepsom stave (mozno este horsom). Citanie sa tak spomalilo, ze resilvering 128 GB trval niekolko hodin a nezvladol precitat asi 50 sektorov. Nastastie ZFS vypisalo, ktorych suborov sa to tykalo a nebolo tam nic dolezite (vecsinou stare dlho nemodifikovane subory). Poucenie pre mna do buducna je najprv pripojit treti disk do mirroru a az potom odpajat vadny. A tiez teraz pouzivam v mirrore rozne SSD disky (asi rok stary Samsung SSD 840 Pro a novy Samsung SSD 850 Pro). Ale ten napad pouzit rozne SSD disky som dostal este pred tym incidentom. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: SSD pro bsd
> Dan Lukes wrote: > > Dalsi pomocne kriterium muze byt "jak dobre se to SSD vyrovna s nahlym > vypadkem napajeni". Pro nejlacinejsi SSD plati, ze pri nahle ztrate napajeni > je ne uplne mala sance na zasadni skody. U tech o trochu drazsich > nejlacinejsich tenhle problem byva vyresen, jenze jen pro prvni obdobi > zivotnosti disku, pricemz neni mozne zjistit, kdy toto obdobi skoncilo. Ja len doplnim, ze nahly vypadok napajania byva problem i pre ZFS. System nemusi potom sam nabootovat. Mne stacilo nabootovat z ineho media a importovat ZFS pool rucne. Na http://open-zfs.org/wiki/Hardware#Power_Failure_Protection je mozne najst zoznam diskov, ktore su zname tym, ze tuto ochranu maju: • Crucial MX200 • Crucial M500 • Crucial M550 • Intel 320/330/335 • Intel 710 • Intel 730 • Intel DC S3500/S3510/S3610/S3700/S3710 • Samsung PM863 • Samsung SM1625 • Samsung SM843T (do not confuse with SM843) • Samsung SM863 • Samsung 845DC Evo • Samsung 845DC Pro • Samsung PM853T Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: SSD pro bsd
> Cejka Rudolf wrote: > > 1) První, když chci mít RAID, musím se o něj starat. Tj. ne "přestože pole > mělo spare disk" (= jednou tam zapíchnu disk navíc a dál se nestarám), > ale "přestože pole dělalo pravidelný patrol read a consistency check" > (= dělají se pravidelné plné kontroly čitelnosti všech sektorů všech > disků a kontroly konzistence kontrolních součtů a výstupy kontroluju). > Nebo u všech disků aspoň pravidelný smart long test, když už nic jiného. Ja som u tých Crucial diskov mal zapnutý periodic ZFS scrub (default 35 days), čo je síce kontrola iba používaných sektorov, ale to by snáď malo byť dostačujúce. A tiež smart long test každý týždeň. > Miroslav Lachman wrote: > > Ano, tomu bych rozumel. Proste zestarnou oba dva stejne rychle, jako by > zestarnul jen jeden - takze je potreba hlidat SMART a pri prvnim naznaku > opotrebovani alespon jeden vymenit. Menil som pri prvom naznaku opotrebovania, teda ked tym bolo myslene FAILING_NOW v smart reporte, co mozno nie. Ono vlastne tie Crucial disky som tu riesil uz pred rokom, kedy som ich uz podozrieval, ze zacinaju umierat (Pomaly zapis na SSD, http://www.freebsd.cz/listserv/archive/users-l/2015q2/029041.html). Tak to asi bola predzvest. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Samovolne odpajanie disku
> Marián Černý wrote: > >>> Co by ste odporucali? Vymenit kabel? Zapojit do ineho portu? >>> >>> Je tam Samsung 850 PRO, Samsung 840 PRO a dva pevne disky WD. Robi to iba >>> ten Samsung 850. >> >> Tipnul bych si problem s napajenim, nebo kabel. Kazdopadne by ti v tomhle >> mohlo pomoct taky zkoumani vystupu SMART (sysutils/smartmontools), jestli se >> tam zvysuji hodnoty nejakych counteru atd. > > Tak som skoro po dvoch mesiacoch prehodil napajacie a SATA kabely medzi dvoma > SSD a dvoma HDD, co tam su. Ale urobilo mi to znovu: Ten disk sa stale odpajal. Dokonca sa pridali chybove hlasky: kernel: can't re-use a leaf (read_ahead)! kernel: can't re-use a leaf (write_cache)! kernel: can't re-use a leaf (sort_io_queue)! Podla nich som ale nasiel tip, ze by to mohol byt SATA kabel, ze ci je to SATA 3 kabel. Tak som kupil SATA 3 kabel a vymenil povodny asi 75 cm SATA kabel v SuperMicro SC731i-300B tower bedni za 50 cm SATA 3 kabel a od vtedy je klud. Je to sice iba 10 dni, ale ku koncu mi to odpajalo kazdych 1-2 dni, tak snad to bude ok. Ani som nevedel, ze SATA 3 kable existuju. Ale co som pozeral nejake testy, tak medzi SATA 2 a SATA 3 nie je rozdiel (v rychlosti). Tak mozno skor pomohlo to, ze ten kabel je kratsi. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Samovolne odpajanie disku
> Dan Lukes wrote: > >> medzi SATA 2 a SATA 3 nie je rozdiel (v rychlosti). > > Jen pro uplnost ... > > SATA 2 = 3.0Gbps; SATA 3 = 6.0Gbps (a SATA 1 = 1.5Gbps) Chcel som napisat, ze podla testov, co som pozeral, tak medzi SATA 2 a SATA 3 *kablami* nie je rozdiel v rychlosti. Konkretne som narazal na tento test: SATA 3Gb/s vs. 6Gb/s Cable Performance (Revisited) https://www.pugetsystems.com/labs/articles/SATA-3Gb-s-vs-6Gb-s-Cable-Performance-Revisited-183/ > ## Conclusion > Our results confirm that despite the faster hardware available today, there > is still no performance difference between SATA 3Gb/s and SATA 6Gb/s cables. > The SATA 3Gb/s revision only supports transfer speeds around 300MB/s, yet we > saw transfer speeds up to 500 MB/s with each cable that we tested. Avsak je to test z February 11, 2013, tak mozno s modernymi SSD by sa sem-tam mozno niekde nejaky problem nasiel. > Vyssi prenosova rychlost znamena vyssi utlum (pri stejnych parametrech > kabelu) a vyssi citlivost na jitter. To dava zmysel. Len ma to nikdy nenapadlo, ze SATA kabel treba riesit. Ten SATA 3 kabel vyzera rovnako. U PATA kablov vyzerali rychlejsie kable inac (mali 2x viacej zil). Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
NAT pred IPsec s pomocou IPFW
Ahojte, mam server s jednou sietovou kartou (em0) a VPN tunelom pomocou IPsec. Cez VPN je dostupny server 10.5.5.5 z verejnej IP adresy jailu 1 (80.0.0.101) a tiez z privatneho rozsahu 10.2.2.0/24. Chcel by som nastavit, aby komunikacia z jailu 2 (80.0.0.102) na server 10.5.5.5 sla cez VPN s prekladom zdrojovej adresy na 10.2.2.102. Nedari sa mi to ale nastavit. Momentalne som v situacii, ze vidim, ze k prekladu adries doslo (tcpdump -i em0 -n host 10.5.5.5): 13:47:26.225691 IP 10.2.2.102 > 10.5.5.5: ICMP echo request, id 64090, seq 0, length 64 Ale v tcpdump -i enc0 sa to uz neobjavi. Ked na hoste pouzijem ping -S 10.2.2.102 10.5.5.5, tak to funguje OK - zobrazi sa to v tcpdump -i enc0. Ako zariadit, aby traffic s prelozenymi adresami bol dalej spracovany cez IPsec? Do konfiguracie IPFW som pridal: gateway_enable="YES" firewall_nat_enable="YES" nat 1 config ip 10.2.2.1 redirect_addr 80.0.0.102 10.2.2.102 add 00999 nat 1 all from 80.0.0.102 to 10.5.5.5 via em0 IPsec mam nakonfigurovany nasledovne: ipsec_enable="YES" ipsec_file="/usr/local/etc/racoon/setkey.conf" racoon_enable="YES" setkey.conf: flush; spdflush; spdadd 80.0.0.101/32 10.5.5.5/32 any -P out ipsec esp/tunnel/80.0.0.1-90.0.0.1/unique; spdadd 10.5.5.5/32 80.0.0.101/32 any -P in ipsec esp/tunnel/90.0.0.1-80.0.0.1/unique; spdadd 10.2.2.0/24 10.5.5.5/32 any -P out ipsec esp/tunnel/80.0.0.1-90.0.0.1/unique; spdadd 10.5.5.5/32 10.2.2.0/24 any -P in ipsec esp/tunnel/90.0.0.1-80.0.0.1/unique; Dakujem za rady Marian Cerny -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: SSD nebo HDD na system
Dan Lukes wrote: > Akorad si nemyslim, ze takovej Intel DC S35x0 je "serverovej". A ktore su? Intel DC S3700 200GB SSD je ok? Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Instalacia FreeBSD 11.0 z USB a GPT CORRUPT part
>> prekvapila ma hlaska: >> GEOM: da0: the secondary GPT table is corrupt or invalid. >> GEOM: da0: the secondary GPT header is not in the last LBA. > >> Tusi niekto preco gpart oznacuje instalacny USB kluc pre 64 aj 32 bitou >> verziu 11 CORRUPT? > > Resenim je, opravit GPT z primarni tabulky. > > Prikaz "gpart recover" (vice info v man gpart) Ja mam podobny problem u USB disku s GPT, ktory jsem si sam vytvoril. GEOM: da0: the secondary GPT table is corrupt or invalid. GEOM: da0: using the primary only -- recovery suggested. Po `gpart recover` se to opravi. Ale kdyz z neho znovu nabootuju, tak je problem zpet - ta hlaska se objevi uz pri bootu. Pouzivam ho na bootovani jedneho serveru s sifrovanym diskem pomoci GELI. Vsude je GPT a ZFS. Neco tu zalozni kopii partition tabulky pri vypinani nebo bootu asi znici. Ten USB disk vypada takto: root@shockwave:~ # gpart show da0 => 34 15364349 da0 GPT (7.3G) [CORRUPT] 34 990 - free - (495K) 1024 10241 freebsd-boot (512K) 2048 153620482 freebsd-zfs (7.3G) 15364096 287 - free - (144K) Problem me netrapi, proste to ignoruju. Posilam to jen pro info. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: ZFS - automatické snapshoty s rotací
> Potřeboval bych přes cron dělat pravidelné "zálohy" s rotací pomocí ZFS > snapshotů. > Pokud někdo něco takového děláte, jaký nástroj na to používáte? Pouzivam vlastny skript (pozri nizsie), ktory spustam cez cron: # ZFS Backups 2 1-23* * * rootsh /opt/sbin/zfs-backup.sh hourly 2 0 * * * rootsh /opt/sbin/zfs-backup.sh daily 32 0 1 * * rootsh /opt/sbin/zfs-backup.sh monthly Vytvara to hodinove snapshoty 24 hodin spat, denne 7 dni spat a mesacne 6 mesiacov spat. @monthly-2016-09-01-00:00 @monthly-2016-10-01-00:00 @monthly-2016-11-01-00:00 @monthly-2016-12-01-00:00 @monthly-2017-01-01-00:00 @monthly-2017-02-01-00:00 @daily-2017-02-10-00:00 @daily-2017-02-11-00:00 @daily-2017-02-12-00:00 @daily-2017-02-13-00:00 @daily-2017-02-14-00:00 @daily-2017-02-15-00:00 @hourly-2017-02-15-11:00 @hourly-2017-02-15-12:00 @hourly-2017-02-15-13:00 @hourly-2017-02-15-14:00 @hourly-2017-02-15-15:00 @hourly-2017-02-15-16:00 @hourly-2017-02-15-17:00 @hourly-2017-02-15-18:00 @hourly-2017-02-15-19:00 @hourly-2017-02-15-20:00 @hourly-2017-02-15-21:00 @hourly-2017-02-15-22:00 @hourly-2017-02-15-23:00 @daily-2017-02-16-00:00 @hourly-2017-02-16-01:00 @hourly-2017-02-16-02:00 @hourly-2017-02-16-03:00 @hourly-2017-02-16-04:00 @hourly-2017-02-16-05:00 @hourly-2017-02-16-06:00 @hourly-2017-02-16-07:00 @hourly-2017-02-16-08:00 @hourly-2017-02-16-09:00 @hourly-2017-02-16-10:00 Mam k tomu este periodic cleanup script, ktory maze stare snapshoty, ktore tam zostanu, ked sa ten skript nespusti - napriklad kvoli vypadku serveru. zfs-backup.sh: set -e type=$1 case "$type" in hourly) adjust=-24H format="%F-%H:00" ;; daily) adjust=-7d format="%F-00:00" ;; monthly) adjust=-6m format="%F-00:00" ;; *) echo Invalid type $type >&2 exit 1 ;; esac pools=`zpool list -H -o name` # # Delete old (rotating-out) snapshots # # old=$type-`date -v$adjust +$format` for pool in $pools do # Maly HACK ako sa vyhnut hlaske, ze snaphost s danym menom neexistuje. # Vytvorime si snaphost priamo na hlavny dataset poolu, ktory vzapeti # hned zmazeme. zfs snapshot $pool@$old zfs destroy -r $pool@$old done # # Create new snapshot # # datasets=`zfs list -d 1 -H -o name $pools | grep /` new=$type-`date +$format` for dataset in $datasets do zfs snapshot -r $dataset@$new done -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Instalacia FreeBSD 11.0 z USB a GPT CORRUPT part
>> Po `gpart recover` se to opravi. Ale kdyz z neho znovu nabootuju, tak je >> problem zpet - ta hlaska se objevi uz pri bootu. > > sysctl kern.geom.debugflags=16 > náhodou nepomůže? Před gpart recover. Nie, to nepomoze. Z toho USB disku iba nabootuje kernel ale montuje sa ZFS z HDD, takže si myslím, že tie boot sektory USB disku nie su nejako systémom blokované. A keď dam gpart recover a znovu ten disk vložím, tak už je ok. Ta chyba sa zobrazí až po nabootovaní. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Instalacia FreeBSD 11.0 z USB a GPT CORRUPT part
On 16. Feb 2017, at 15:41, Dan Lukes wrote: Po `gpart recover` se to opravi. Ale kdyz z neho znovu nabootuju, tak je problem zpet - ta hlaska se objevi uz pri bootu. > >> A keď dam gpart recover a znovu ten disk vložím, tak už je ok. Ta chyba sa >> zobrazí až po nabootovaní. > > No, to skoro vypada, jak, kdyaz ti ten sektor nekdo prepise. > > Coz ma dve mozna vysvetleni - > a) blbe "rozpartitionovano" a nedovolene se prekryvajici struktury > b) nekdo, kdo pise kam nema > > Zalozni GPT je v poslednim sektoru. Nemel by byt problem to pred restartem, > kdyz je jeste v poradku, overit - a podivat se, co je v tomtez sektoru po > restartu, kdyz si to zacne znovu stezovat. > > Podle toho co tam bude se muze podarit uhadnout, kdo to tam napsal ... Pohral jsem si s tim a zjistil jsem, ze to asi prepisuje BIOS. Po recovery a vypnutí PC je to jeste ok (overeno na druhem PC). Pri bootu se to ale zmeni. Zmena je jiz po zobrazeni boot menu (F10). Po nabootovani FreeBSD se to jeste oproti stavu pri zobrazeni boot menu opet zmeni. Dumpoval jsem poslednich 16 KB (128 partitions * 128 B) + 512 B: dd if=/dev/da0 of=2.secondary.gpt bs=512 skip=15364415 33+0 records in 33+0 records out 16896 bytes transferred in 0.009747 secs (1733451 bytes/sec) Data je mozne najit tu: https://www.dropbox.com/sh/ti8z5lgm5xnlglo/AAATOoP-fHePvvPXvzrP7qT-a?dl=1 $ md5 *.gpt MD5 (1.primary.gpt) = 7df895fe9a8c141ff9c5b3d3a26b23d8 MD5 (2.secondary.after.boot.gpt) = 01019a257e6945cbaea001bdd7a8a1d9 MD5 (3.secondary.recovered.gpt) = 8e0d16163129e32bd075fb288f988f6f MD5 (4.secondary.after.shutdown.gpt) = 8e0d16163129e32bd075fb288f988f6f MD5 (5.secondary.after.boot.menu.gpt) = 1d6dd175d70d2459e1e4a0a4263db021 Co jsem se na to dival, data partition (16 KB) jsou OK, meni se jenom partition table header (poslední blok). Chybi napriklad (CRC32 of partition array)[1]… je tam nula a v "Reserverd; must be zeroes” jsou nejake garbage stringy. Pri jednom boote tam bylo: > lors d'une coupure d'alimentation. Reste arrêté : le système reste arrêté une > fois que l'alimentation est rétablie. Dernier état : restaure l'état de > fonctionnement dans lequel se trouvait le système avant la (google translate:) > During a power outage. Remaining stopped: The system remains off after power > is restored. Last Status: Restores the operating state in which the system > was located before the Pri druhem: > ror. > PD Tolerance > emory Optimization Dual Unbalanced > Memory Optimization Single > 10 > 11 > 12 > 13 > 14 > 15 > Current Memory Setting > NULL > Memory Frequency > Change values here to override SPD Auto detection. > tCL > Set to o Dal jsem to nezkoumal. Mam to za bug BIOSu. Je tam maticna deska Intel DG43NB Nobletown. Budu to ignorovat. Marian [1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_.28LBA_1.29 -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Instalacia FreeBSD 11.0 z USB a GPT CORRUPT part
Dan Lukes wrote: >> Mam to za bug BIOSu. Je tam maticna deska Intel DG43NB Nobletown. Budu to >> ignorovat. > > Predpokladam, ze tam mas posledni verzi BIOSu (0107), ze v BIOSu nemas radic > nastaven do RAID rezimu. Mel jsem tam verzi 0082, upgradoval na 0107, ale dela to porad. RAID rezim nemam. Necham to plavat, to USB je jenom na bootovani. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
whois v jailu
Nefunguje mi whois v jailu pro COM domenu. Pro CZ nebo SK ano.
Nejdriv to vypise informace z "IANA WHOIS server”:
% IANA WHOIS server
...
nserver: A.GTLD-SERVERS.NET 192.5.6.30 2001:503:a83e:0:0:0:2:30
...
whois:whois.verisign-grs.com
…
A nakonec:
whois: connect(): Protocol not supported
U host systemu whois na COM domenu funguje. Kdyz porovnavam vystup z `truss`,
tak tam vidim, ze rozdil je v tom, ze v jailu pokusy o otevreni IPv6 spojeni
konci chybou “Protocol not supported” a u host systemu “No route to host”:
Jail:
socket(PF_INET6,SOCK_DGRAM|SOCK_CLOEXEC,17) ERR#43 'Protocol not
supported'
socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,17) = 3 (0x3)
connect(3,{ AF_INET 199.7.60.74:1 },16) = 0 (0x0)
getsockname(3,{ AF_INET 80.79.31.16:38810 },0x7fffe26c) = 0 (0x0)
close(3) = 0 (0x0)
socket(PF_INET,SOCK_STREAM|SOCK_NONBLOCK,6) = 3 (0x3)
connect(3,{ AF_INET 199.7.60.74:43 },16) ERR#36 'Operation now in
progress'
poll({ 3/POLLIN|POLLOUT|POLLERR|POLLHUP },1,180) = 0 (0x0)
socket(PF_INET6,SOCK_STREAM|SOCK_NONBLOCK,6) ERR#43 'Protocol not
supported'
close(3) = 0 (0x0)
whois: connect(): Protocol not supported
Host:
socket(PF_INET6,SOCK_DGRAM|SOCK_CLOEXEC,17) = 3 (0x3)
connect(3,{ AF_INET6 [2001:503:5419:1000::74]:1 },28) ERR#65 'No route to
host'
close(3) = 0 (0x0)
socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,17) = 3 (0x3)
connect(3,{ AF_INET 199.7.61.74:1 },16) = 0 (0x0)
getsockname(3,{ AF_INET 80.79.31.16:30969 },0x7fffe26c) = 0 (0x0)
close(3) = 0 (0x0)
socket(PF_INET,SOCK_STREAM|SOCK_NONBLOCK,6) = 3 (0x3)
connect(3,{ AF_INET 199.7.61.74:43 },16) ERR#36 'Operation now in
progress'
poll({ 3/POLLIN|POLLOUT|POLLERR|POLLHUP },1,180) = 0 (0x0)
socket(PF_INET6,SOCK_STREAM|SOCK_NONBLOCK,6) = 4 (0x4)
connect(4,{ AF_INET6 [2001:503:5419:1000::74]:43 },28) ERR#65 'No route to
host'
close(4) = 0 (0x0)
poll({ 3/POLLIN|POLLOUT|POLLERR|POLLHUP },1,-1) = 1 (0x1)
Pripada mi to jako chyba whois aplikace, ktera predcasne ukonci zpracovani v
pripade, ze dostane odpoved Protocol not supported na pokus o otevreni IPv6
spojeni, pritom kdyby pokracovala s IPv4, tak by to proslo.
Poradi nekdo jak to co nejjednoduseji rozchodit?
Marian
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
Re: whois v jailu
Dan Lukes wrote: > nevim o jakem FreeBSD je rec. Takze jsem to zkoumal na 10.3-R 11.0-RELEASE-p8 >> Pripada mi to jako chyba whois aplikace, ktera predcasne ukonci zpracovani v >> pripade, ze dostane odpoved Protocol not supported na pokus o otevreni IPv6 >> spojeni > > To zdrojaky nepotvrzuji. Whois si vyzada seznam IP adres pro dane jmeno a > nasledne pres vsechny radky, ktere dostane, to zkousi. > > Pricemz, kdyz selze 'socket()' tak poracuje dalsi variantou, bez ohledu na > konkretni chybovy kod. > > Nasleduje connect(), kde je logika trochu slozitejsi, ale i tady v trivialnim > pripade, kdy IPv6 pokus predchazi IPv4 pokusu plati, ze selhany connect() > vede na dalsi pokus a to znovu bez ohledu na chybovy kod. > > Takze bud' je to na teto verzi v poradku a na te tve je to jinak, nebo je > pricina pozorovaneho jevu slozitejsi/jina. Z toho truss-u bylo videt, ze se zkousi stejne IPv6 adresy a podobne IPv4 adresy. Z chybove hlasky jsem odvodil, ze to tedy souvisi s tim nepodporovanym IPv6. Ale mozna byl vypadek u te jedne IPv4 adresy a u hosta se porad zkousela funkcni a v jailu ta nefuncni. > Mirek: >> Me spis prekvapuje, ze mi polovina requestu projde a druha konci tim >> Protocol not supported. > > No, to by mohlo znamenat, ze nejake resolveni vraci dva zaznamy ve > stridajicim se poradi (stridani je "normalni" vlastnost DNS) a problem > nastava jen pri zcela konkretnim poradi zaznamu z DNS. Aha, tak me to ted pro zmenu porad funguje. Zkousim whois google.com. Nameserver je bind910-9.10.4P6 v tom jailu. Budu to jeste sledovat. Upgradoval jsem FreeBSD 9.3 na 11.0 a presouval jsem DNS server do jailu. A vypadli mi nejake kontrolni skripty pouzivajici whois. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Binarna kompatibilita FBSD 10.1 s FBSD9
Dan Lukes wrote: >> c) napriek tomu vsetkemu mi sudo, pkg (a nasledne aj mysql55-server) >> vyhlasili chybu ze im chybaju nejake kniznice (ak si pamatam tak >> libcrypt.6). > > To je asi vlastnost konkretni metody upgrade (tedy - freebsd-update). > Odhaduju, ze ono v ramci upgrade rovnou, v jednom kroku, zlikviduje systemove > knihovny stare verze. Takze po restartu skutecne ledacos (pravdepodobne > vetsina) nenastartuje, protoze tomu budou shazet systemove sdilene knihovny, > bez nichz to nema sanci. > > Ja upgraduju pomoci 'make installworld installkernel' kde je uklid starych > knihoven (make delete-old delete-old-libs) samostatnym krokem - a ten se dela > az po reinstalaci portu. Aj pri freebsd-update sa robi major upgrade viac-krokovo - s uklidem starych knihoven: 1) freebsd-update upgrade -r X.Y-RELEASE 2) freebsd-update install 3) shutdown -r now 4) freebsd-update install 5) pkg-static upgrade -f 6) freebsd-update install volitelne: 7) shutdown -r now Uklid starych knihoven sa robi v kroku 6 po aktualizacii vsetkych balickov v kroku 5. Na upgrade balickov v kroku 5 je mozne pouzit aj nieco ine. Ja tento postup pouzivam k mojej spokojnosti. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: pearl má problémy se závislostma-BSD 12
> Dan Lukes wrote: > > Jestlize si balicky prekladas sam, tak tvoje nastaveni (a aktualne > instalovana verze Perlu) urcuje, jaka verze perlu se ma pouzit. Jestli chces > pouzivat 5.28 a "neco" si nainstalovalo verzi 5.26, pak to asi nemas dobre > nastavene. Pochopitelne, nemuzes si naprekladat cast veci, pak zmenit > nastaveni ohledne preferovane verze Perlu a pak pokracovat v prekladech a > cekat, ze to bude fungovat. S prekladaním perlu som mal už niekoľko krát problémy. Väčšinou približne keď sa mení default verzia. Inštalujem z portov pomocou make install a predtým vždy všetky nainštalované balíčky odinštalujem. 20161103: Default verzia Perlu bola zmenená z 5.20 na 5.24. Napriek tomu, že som mal nainštalovaný Perl 5.24, tak ho Bison nenašiel. Musel som pridať DEFAULT_VERSIONS += perl5=5.24 aby ho Bison našiel. 20180330: p5-Locale-gettext-1.07 => bison => MariaDB nevedela nájsť Perl, aj keď bol v DEFAULT_VERSIONS nastavená verzia 5.24 a ten bol nainštalovaný. Aktualizoval som verziu v DEFAULT_VERSIONS na vtedy aktuálnu 5.26. Naviac som musel umazať /tmp/PERL5_DEFAULT, ináč preklad nefungoval. 20181213: Default verzie bola zmenená na 5.28 a preklad začal vyhadzovať nejaké warningy. Zrušil som teda custom nastavenie verzie Perlu v DEFAULT_VERSIONS, nech sa “vždy” použije aktuálna default verzia, ale i tak sa to prekladalo so starým perlom. Musel som umazať /tmp/PERL5_DEFAULT. Takže osobne si myslím, že tam sú v systéme portov u Perlu alebo niektorých balíčkoch, ktoré ho používajú, nejaké nedotiahnuté veci. Marián -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: FreeBSD jednoduchy logger
Jozef Drahovsky wrote:
> Viacero rokov som pouzival namiesto syslogu syslog-ng s upravenym
> konfiguracnym suborom tak aby mi vsetko islo 1:1 do naseldovnej suborovej
> struktury:
> Co zdroj to adresar a subor v tvare -MM-DD.txt
>
> source src_mes {file("/var/log/messages"); };
> destination d_mes { file( "/var/log-ng/messages/$YEAR-$MONTH-$DAY.txt"
> create_dirs(yes) ); };
> log { source(src_mes); destination(d_mes);};
>
> Otazka: Ma niekto napad ako jednoducho nahradit syslog, tak aby som dostaval
> pozadovnu strukturu suborov?
Pomocou newsyslog by malo ísť jednoducho dosiahnúť to, aby sa z
/var/log/messages generovalo /var/log/messages.2019-01-29. Stačí púšťať
newsyslog s parametrom -t %F a rotovanie nastaviť na každý deň (when nastaviť
na @T00). Akurát tam asi bude dátum rotovania - teda +1 deň, než by si chcel.
Nevyhovuje to presne požiadavkám, ale možno sa to hodí (napríklad s doplnením
manuálneho cron skriptu, ktorý to popresúva, kam chceš).
Marián
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
Re: SH a funkcie / primarni IP v jailu
>> Stejne ten jail mas na fs pristupnej pod hlavnim rootem, tak nevidim duvod >> proc bys nemohl appendnout nebo 'sed-nout' konfiguracni soubor uvnitr jailu >> z master hosta. > > Protoze kdyz resim nejaky problem, tak hledam univerzalni reseni a ne reseni, > ktere priohnu jen svemu prostredi. Chtel bych proste vedet, jestli existuje > univerzalni zpusob, ktery funguje uvnitr jailu bez znalosti / kontroly jeho > vnejsiho okoli. Podle me to bude vzdy ta prvni IP adresa. A i kdyby ne, tak neni problem povolit vsechny, ne? To je asi nejuniverzalnejsi reseni - bude fungovat i kdyby se implementce pozdeji zmenila. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: SH a funkcie / primarni IP v jailu
> Ale porad jsem zvedavy, jestli lze systematicky zjistit tu primarni. Co jsem > zkousel googlit, tak na nekterych tucnacich existuje cosi jako > ipv4_default_address Napadlo ma taketo riesenie: nc -l localhost 1500 & sockstat -4 -p 1500 killall nc (Netestoval som na jaile s viacerymi IP, ale malo by fungovat.) Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: zalohovani zmenenych + novych souboru / Kolko casov suboru pozna FreeBSD?
> On 16 Mar 2019, at 23:16, Miroslav Lachman wrote: > > V soucasnosti se zalohuje rsyncem (uz asi 10 let) a zacina s tim byt problem, > jak je souboru vic a vic, tak strasne dlouho trva, nez se zjisti, kde vsude > se zmenily soubory, nebo nekdo nahral nejaky novy, pripadne stary soubor > nekdo smazal. Predpokladam, ze rsync prave projizdi celou adresarovou > strukturu a hleda zmeny mtime / ctime na zdrojove a cilove strane. Denne se > takhle synchronizuje sotva 1GB dat, ale trva to asi 6-8 hodin, podle vytizeni > disku... a to je ten problem, ze to ovlivnuje produkcni provoz. > > Existuje nejake reseni, ktere by dokazalo bezet na pozadi, z kernelu dostavat > informaci o tom, ktere soubory se zmenily a pak je jednou za den je > synchronizovat na zalohovaci stroj? Na to mi príde celkom dobré ZFS, kde je možné zálohovať tak, že sa posiela iba rozdiel medzi dvoma snapshotmi. (UFS má tiež snapshoty, ale či je teoreticky možné poslať rozdielovú zálohu netuším. O žiadnej utilite neviem.) Marián -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: lighttpd, uid 80: exited on signal 11
Dan Lukes wrote: > Program bez gdb pada, ale s gdb ne, takze problem je nedebugovatelny. > Pokud problem uz jednou vyresila reinstalace, lze vyslovit hypotezu, ze to > vyresi i podruhe. Keby problem nevyriesila reinstalacia, tak by mohlo byt mozne debugovat pomocou debug printov. Pridat si na vhodne miesta do programu printy “was here”, “also here”, “count is %d” a tak. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Virtual FreeBSD hosting
Neslo by to cez Amazon AWS EC2? FreeBSD je tam podporovane: https://aws.amazon.com/marketplace/pp/B07L6QV354/ Planoval som tam rozbehavat servery pre jeden projekt, ale nakoniec sa ten projekt zrusil, tak nemam osobne skusenosti. Ale co som si nacital, tak by s tym nemal byt problem akurat tam bola nejaka minimalne odporucana velkost instancie (ale uz si nepametam aka). Marian > On 21 Apr 2019, at 21:49, Jozef Drahovsky > wrote: > > Hladam poskytovatela sluzby pre virtualny server s OS FreeBSD mimo EU. > Napri: 1xIPv4, (+/-IPv6), 1GB ram, 20GB disk, zatazenie minimálne, bude > sluzit len ako geograficka zaloha pre bezne sluzby > Pre Unbutu, debian, fedora, windows som ich nasiel vela, ale pre FreeBSD nie. > > Sice niektore v reklame pre vyhladavace maju uvedene aj FreeBSD, ale ked > pozeram na ich instalacny tools, > tak sa da instraloval len z ich ISO a FreeBSD tam nie je. > > Viete odporucit ked takyto virtualny server hosting pre FreeBSD hladat? > > Jozef > > -- > FreeBSD mailing list (users-l@freebsd.cz) > http://www.freebsd.cz/listserv/listinfo/users-l -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Root Remount (reroot) ze ZFS na jine ZFS
Zdravim, od FreeBSD 11.0 je mozne remountnut root (reboot -r) (http://www.freebsd.cz/news/status/report-2015-10-2015-12.html#Root-Remount). Trochu jsem se s tim hral - da se rerootovat na NFS root - vhodne napriklad kdyz nefunguje PXE boot - da se rerootovat na temporary memory filesystem, predelat rootfs napriklad z UFS na ZFS a rerootovat zpet (https://people.freebsd.org/~lidl/blog/re-root.html) - da se rerootovat na sifrovany filesystem, predem odemceny pres geli attach Ted zkousim ten posledny pripad. Mam nesifrovany ZFS pool (base), do ktereho nabootuju, tam pripojim sifrovany ZFS pool (private) a pak do nej rerootuju. Ale nastava problem, ze pred rerootem se ten base pool neodmontuje cely (jenom root) a nove filesystemy jsou namontovane pres ty stare: private/ROOT/default on / (zfs, local, noatime, nfsv4acls) devfs on /dev (devfs, local, multilabel) base/home on /home (zfs, local, noatime, nfsv4acls) private/home on /home (zfs, local, noatime, nfsv4acls) private/tmp on /tmp (zfs, local, noatime, nfsv4acls) base/tmp on /tmp (zfs, local, noatime, nfsv4acls) base/var/crash on /var/crash (zfs, local, noatime, nfsv4acls) private/var/crash on /var/crash (zfs, local, noatime, nfsv4acls) base/var/log on /var/log (zfs, local, noatime, nfsv4acls) private/var/log on /var/log (zfs, local, noatime, nfsv4acls) base/var/mail on /var/mail (zfs, local, noatime, nfsv4acls) private/var/mail on /var/mail (zfs, local, noatime, nfsv4acls) private/var/tmp on /var/tmp (zfs, local, noatime, nfsv4acls) base/var/tmp on /var/tmp (zfs, local, noatime, nfsv4acls) Nevite, jak lze zabezpecit, aby se to kompletne odmontovalo? U rerootu z UFS na ZFS se UFS odmontuje cele. IMHO to vypada na bug. Z manualove stranky reboot(8): -r The system kills all processes, unmounts all filesystems, mounts the new root filesystem, and begins the usual startup sequence. After changing vfs.root.mountfrom with kenv(1), reboot -r can be used to change the root filesystem while preserving kernel state. This requires the tmpfs(5) kernel module to be loaded because init(8) needs a place to store itself after the old root is unmounted, but before the new root is in place. Je tam uvedeno "unmounts all filesystems". Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Root Remount (reroot) ze ZFS na jine ZFS
On 29 May 2019, at 13:54, Dan Lukes wrote: >> Nevite, jak lze zabezpecit, aby se to kompletne odmontovalo? > > Proste je pred volanim reboot -r odmountovat explicitne ? Ale jak? Rucne zavolat force unmount? To mi neprijde ciste. Nejake aplikace muzou mit otevrene soubory napriklad ve /var/run, pripadne syslogd v /var/log. Muzu ukoncit vetsinu aplikaci. Ale radsi bych byl kdyby se o to postaral system. Nebo je mozne vytvorit nejaky shutdown script, ktery se zavola ve vhodne chvili pri tom reboot -r? Ja se moc do toho, jak to funguje pri vypinani, nevyznam. >> Mam nesifrovany ZFS pool (base), do ktereho nabootuju, tam pripojim >> sifrovany ZFS pool (private) a pak do nej rerootuju. > > Jen ze zvedavosti - takze to mas tak, ze pocitac nastartuje jen pokud je > pritomna obsluha, ktera zada heslo ? > > Ja delal neco podobneho, ale nemaje o existenci reroot zadne poneti, tak to > mam tak, ze pocitac bootuje z flash (ktera sama je zabezpecena a nejprve je > nutne ji odemknout zadanim kodu na HW klavesnici, ktera je primo na flashce), > v ramci toho bootu se (z flash) nacte klic pro GELI, obsluha navic muzu zadat > i heslo - a pak system dobootuje a rovnou mountne uz odemceny svaazek na > disku. Ted, kdyz jsme se dozvedel o reroot, tak mi ale stejne nevychazi, ze > to ma smysl predelavat. Klic stejne musi odnekud prijit, na nesifrovanem > svazku lezet nemuze, takze bez flash se stejne neobejdu - no a to uz pak > nepotrebuju ten reroot. Ja jsem mel neco podobneho na FreeBSD 10. Nezabezpecena flash, ze ktere se bootuje a na ktere je klic pro GELI. Pri bootu se pak jeste zadavalo heslo. V /boot/loader.conf jsem mel: zfs_load="YES" aesni_load="YES" geom_eli_load="YES" vfs.root.mountfrom="zfs:private/ROOT/default" geli_ada0p4_keyfile0_load="YES" geli_ada0p4_keyfile0_type="ada0p4:geli_keyfile0" geli_ada0p4_keyfile0_name="/boot/keys/private.key" Takze obsluha musela mit flash a znat heslo. Fungovalo to OK, ale byl problem s bootem z flash - neslo nastavit v BIOSu, muselo se pres F11. A pak s USB klavesnici. Kdyz system chtel heslo, tak klavesnica jeste nebyla ready a muselo se to heslo zadavat na x krat. A bylo tam omezeni, ze byla potreba obsluha na miste. Ted jsem to upravil, ze se bootuje z ciste nezabezpecene instalace jenom s nastaveným SSH. Pres SSH sa nahraje klic pro GELI do memory filesystemu, odemkne s heslem a rerootuje. Je to min bezpecne, ale je to mozne udelat vzdalene. Nekdo s fyzickym pristupem a znalostmi by mohl upravit tu nezabezpecenou cast a pri vzdalenem odemykani odchytit klic a heslo - nebo upravit kernel. To ale povazuji v mem pripade za malo pravdepodobne. Navic to mam vice-mene na hrani. Slo by bootovat vzdy z flash disku a mit ten remote boot jenom jako fail safe. BTW ta zabezpecena flash s HW klavesnici je fajn vec. > Ale je pravda, ze ja pro rootovske svazku zasadne nepouzivam ZFS. Me se libi ZFS Boot Environments. Ne ze bych to nekdy potreboval pouzit ;-). Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Root Remount (reroot) ze ZFS na jine ZFS
Dan Lukes wrote: > Ale zpatky k tomu co teda vlastne "reboot -r" udela. Dekuji za podrobnou analyzu. > vfs_unmountall(), zde je asi podstatne vedet, ze funkce nema navratovou > hodnotu a tedy schopnost signalizovat, ze se unmount neceho nepovedl - jen se > to napise na konzoli (syslog uz nefunguje) Na konzoli ale zadnou chybu nemam. > Ja sice vim, jak probiha shutdown systemu, ale nevim, nakolik 'reboot -r' > provadi opravdu shutdown. > > Pokud ano, tak se pousti /etc/rc.shutdown a v ramci nej se normalne volaji > rc.d scripty (ty, ktere obsahuji KEYWORD shutdown) a spousti s parametrem > "stop". Mezi nimi mj. i /etc/rc.d/local ktery spusti (pokud existuje) > /etc/shutdown.local Podle hlasek na konzole ten reboot provadi i ty shutdown skripty. Mimochodem, ten local script ma byt /etc/rc.shutdown.local (s predponou rc. navic). Reportoval jsem to jako bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238448 Vytvoril jsem si tedy vlastni skript s BEFORE: root (v rcorder se zobrazuje jako prvni - tedy pri shutdownu posledni), kde jsem se snazil odmontovat pri shutdown ty filesystemy. Ty se mi podarilo odmontovat (akorat /var/log jsem musel force-odmontovat). Tim jsem ale zjistil, ze problem neni s tim, ze se ty filesystemy neodmontuji, ale ze se znovu namontuji. System vidi dva pooly - base a private a namontovava vsechny filesystemy s nastavenym mountpoint. Predpokladal jsem, ze po rerootu se to bude tvarit jako jiny host, ale oba hosty maji stejne /etc/hostid (protoze se generuje z kenv -q smbios.system.uuid). Zkusil jsem v base instalaci zmenit rucne /etc/hostid, ale po rerootu se filesystemy z base i tak namontuji. Nevim jak zabezpecit, aby po tom rerootu system povazoval ten base pool za exportnuty. Exportovat ho pri shutdownu asi neni spravne, kdyz je na tom root. Nejlpesi by bylo, aby po tom rerootu povazoval system ten base pool za pool jineho systemu. > To ano, ale o to mi jde - aby pocitac utocnikovi ty data neodemknul, kdyz > odnese cely pocitac. Ale to myslim, ze moje reseni splnuje taky. Kdyz si nekdo pocitac odnese, tak mu to vzdalene neodemknu (neprihlasim se). Kdyz nekdo ziska klic i tak heslo. Proste to neni tak bezpecne, jako Tvoje reseni, ale pro moje potreby dostacuje. > Me se nelibi ZFS ;-) To tady asi vetsina uz vi ;-). Takze jsem ani necekal, ze budes na muj dotaz reagovat. Moc dekuju, ze si reagoval. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Root Remount (reroot) ze ZFS na jine ZFS
Dan Lukes wrote: >>> Ja sice vim, jak probiha shutdown systemu, ale nevim, nakolik 'reboot -r' >>> provadi opravdu shutdown. >> Podle hlasek na konzole ten reboot provadi i ty shutdown skripty. > > To je vlastni - podle te analyzy nic takoveho nedela. Takze mi, zrejme, neco > zasadniho uniklo. Taky mi prislo, ze podle te analyzy by to nemelo delat. Ale kdyz jsem pak hledal tu chybovou hlasku, tak jsem videl, ze to vypina procesy (napriklad SSH), tak jsem zkusil ten shutdown skript a pustil se taky. >> Predpokladal jsem, ze po rerootu se to bude tvarit jako jiny host, ale oba >> hosty maji stejne /etc/hostid >> Nevim jak zabezpecit, aby po tom rerootu system povazoval ten base pool za >> exportnuty. > > Ted jsem se ztratil, nejspis proto, ze ZFS preci jen nepouzivam. CO znamena > "exportnuty" a k cemu je to dobry ? To je o exportovani svazku pres NFS ? I > tam mas nastroje na "manualni ovladani" - zfs share a zfs unshare. Taky ZFS az tak detailne neznam. Ten import/export nesouvisi s NFS. Kdyz pripojis novy pool (napriklad USB se ZFS), tak se automaticky neimportuje (“nenamountuje”). Musis nejdriv udelat “zfs import nazev_poolu”. Pak kdyz ukoncis praci, tak udelas "zfs export nazev_poolu”. Tim se mimo jine odmontuji namontovane filesystemy, ale hlavne se poznaci nekam do toho poolu, ze ten pool je exportovany. Kdyz mas ZFS na systemovem disku, tak ten pool neni exportovany. Pri propojeni disku k jinemu pocitaci se automaticky nepripoji. Musis ho nejdriv importovat. To ale skonci chybou, ze ten pool nebyl exportovany. Musi se importovat s parametrem -f (force). Takze ZFS si nekam do poolu uklada, jestli je pool exportovany a kdyz ne, ktery pocitac ho mel posledne importovany. Nejvic by se mi hodilo, kdyby po rerootu si ten novy system z pohledu ZFS myslel, ze je “jiny pocitac”. Ted ale kdyz se divam do /etc/rc.d/zfs, tak ten dela `zfs mount -va`, takze by melo stacit udelat rc.skript, ktery se pusti pred tim zfs a ktery ten base pool exportuje. Az se k tomu zase dostanu, tak to vyzkousim. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Root Remount (reroot) ze ZFS na jine ZFS [SOLVED]
Dan Lukes wrote:
> Zrejme mi unika duvod, proc trvas na importu. Ano, tim vznika potiz - bez
> predchoziho exportu import mozny neni.
Kdyz chces namontovat dataset (file system) z poolu, tak musi byt pool
importovany.
Kdyz se bootuje ze ZFS, tak se myslim ten pool importuje implicitne a myslim,
ze dokonce i kdyz byl pouzivan na jinem pocitaci a nebyl exportovany. Ale
nejsem si uplne jisty.
>> Ted ale kdyz se divam do /etc/rc.d/zfs, tak ten dela `zfs mount -va`, takze
>> by melo stacit udelat rc.skript, ktery se pusti pred tim zfs a ktery ten
>> base pool exportuje
>
> Kdyz to jde dolu. A kdyz to jde nahodu, tak zase naimportuje. Nebo ne ?
Ne. Kdyz to jde dolu tak to exportovat nemuzu, kdyz je jeste namontovany root.
A ten se odmontuje az po tech shutdown skriptech.
Kdyz to jde nahoru, tak jsou oba pooly v case spusteni /etc/rc.d/zfs
importovane. Tak jsem to myslel tak, ze pred /etc/rc.d/zfs ten base pool
exportuju (a `zfs mount -va` ty filesystemy/datasety nenamontuje).
>> Az se k tomu zase dostanu, tak to vyzkousim.
>
> Na to ti staci rc.d script s
>
> # REQUIRE: zfsbe
> # BEFORE: zfs
Diky za tip. Dal jsem to takto a funguje to bez problemu.
/etc/rc.d/majo-export-base
#!/bin/sh
#
# Based on /etc/rc.d/local
#
# PROVIDE: majo-export-base
# REQUIRE: zfsbe
# BEFORE: zfs
. /etc/rc.subr
name="local"
desc="Export base ZFS pool after reroot"
start_cmd="local_start"
stop_cmd="local_stop"
local_start()
{
echo 'Majo base:'
zpool export base
}
local_stop()
{
}
load_rc_config $name
run_rc_command "$1"
>> Nejvic by se mi hodilo, kdyby po rerootu si ten novy system z pohledu ZFS
>> myslel, ze je “jiny pocitac”.
>
> To by ti ale preci nepomohlo. Ten zpool by nebyl exportovany, nebyl by ani na
> tom novem pocitaci naimportovany, takze bys byl v situaci kterou nelze
> vyresit "normalne", nutne jsou recovery postupy. To mi moc jako "by se
> hodilo" stav nepripada.
No prave pred rerootem ho pouzival host s ID A a neexportoval ho… po rerootu je
to host s ID B… a protoze neni exportovany a posledne ho pouzival host s ID A,
tak si ho host s ID B nebude vsimat. Teda to jsem ocekaval.
Jenze host B po rerootu ma naimportovane oba pooly. “Svuj” private pool
implicitne, protoze z neho bootuje. A ten “cizi” base asi proto, ze to “zustane
v kernelu” u toho rerootu.
Vypada to tak, ze ZFS skutecne pouziva nakonfigurovane kern.hostid. Usuzuji to
z teto hlasky:
# zpool import -R /mnt private
cannot import 'private': pool may be in use from other system, it was last
accessed by shockwave (hostid: 0xcedff5b7) on Mon Jun 10 14:17:07 2019
Pritom hostid odpovida tomu ktere se vypisuje na konzoli pri bootu.
Zjistit to posledni hostid u ZFS poolu lze pomoci zdb -eC private
(http://wiki.lustre.org/Examining_ZFS_Pools_with_zdb).
Zaver asi je, ze u rerootu zustavaji zarizeni (prenasi se devfs), takze i zfs
zarizeni a tedy i ten zfs pool zustane po rerootu importovany, i kdyz by se
normalne neimportoval, protoze hostid je jine.
> Nemuzu si pomoct, ale v souvislosti se ZFS se mi neodbytne vybavuje Murphyho:
>
>> Počítač je zařízení sloužící k řešení problémů, které by bez něj vůbec
>> nevznikly.
njn.
Marian
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
Re: invalid value 'gnu++17'
Já to dělám stejně. Někdy ale ten freebsd-update zlobí… že nějaké soubory nesprávně updatuje, nebo tam zanechá nějaký bordel. Tak pro jistotu ještě rozbalím po upgradu nový base.txz do /tmp/clean-11.3 a pustím `freebsd-update -b /tmp/clean-11.3 fetch install`… a pak porovnám `diff -r --brief / /tmp/clean-11.3`. Marián > On 9 Oct 2019, at 19:30, > wrote: > > Aha, podivné. Dlělal jsem normálně: > > freebsd-update fetch > freebsd-update install > freebsd-update upgrade -r 11.3-RELEASE > freebsd-update install > reboot > freebsd-update install > > Jaký by měl být nyní postup, půjde to přes freebs-update? Díky :-) > M. > >> No, t je pro preklady vada fatalni. >> >> Nevim jak's presne delal upgrade, ale pokud chybi ld muze chybet i >> ledacos dalsiho. Doporucuju upgrade zopakovat a pak teprve zacit resit >> pripadne dalsi problemy. >> >> Dan > > > -- > FreeBSD mailing list (users-l@freebsd.cz) > http://www.freebsd.cz/listserv/listinfo/users-l -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: pkg ako upratat chyby
> Obcas nieco niekde zblbne a kontrolne sucty nesedia. Dik za info, ani som nevedel, ze existuje pkg check. > lenze teraz mi totozne kontrolne sucty nesedia odrazu na dvoch serveroch, co > same o sebe je varovanie. > > Otazka: ako to zmysluplne dat do poriadku inak ako reinstalaciou servera? Nepomoze force reinstalacia balickov? pkg upgrade -f > xorgproto-2019.2 pouzivam a vyzadovany od php72-gd: 7.2.29 a libX11: > 1.6.9,1libXdmcp: 1.1.3libXext: 1.3.4,1libXpm: 3.5.13 > libXt: 1.2.0,1libxcb: 1.13.1 S tym ja nemam problem. Vytvaram si balicky sam a minimalizujem nepotrebne zavislosti. Mne php72-gd na xorgproto nezavisi. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: pkg ako upratat chyby
>> Dik za info, ani som nevedel, ze existuje pkg check. > > To ukazuje na vanejsi problem - zrejme nectes "daily security run output", > ktery system generuje azdou noc a jehoz text dostava emailem root daneho. A v > nem bys moh videt i bez vedomi, ze nejaky pkg check existuje treba toto: > >> Checking for packages with mismatched checksums: Tak to sa nastastie mylis, security output samozrejme sledujem. Len som asi mal stastie a nikdy som na tento vystup nenarazil. Na serveroch mam v periodic.conf nastavene: security_show_success="NO" ... este spred casu pkg-ng, takze v security output o tom nemam zmienku a na pkg check som zatial inde nenarazil. Zato pkg audit riesim bezne. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: pkg ako upratat chyby
> Upgrade potov robim nasledovne: # portsnap fetch # portsnap update # pkg > upgrade Portsnap je na aktualizáciu /usr/ports (ekvivalent freebsd-update na binárnu aktualizáciu systému, akurát na porty). Keď používaš výlučne balíčky (pkg install, pkg upgrade) a nie porty, tak portsnap (a vlastne ani /usr/ports) vôbec nepotrebuješ. Ale možno to kombinuješ (čomu by som sa ja asi vyhýbal), tak potom ten portsnap používať môžeš… len asi bude chýbať ešte nejaký krok na upgrade ručne inštalovaných portov. Resp. pkg upgrade ich asi upgraduje, len je otázka, aký bol dôvod ich inštalácie z portov. Ak šlo o vlastné configure options, tak ich ten upgrade nahradí balíčkom z (FreeBSD) repository a zmenia sa. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: pkg ako upratat chyby
> Dokocne i kdyz si vsechno prekladam sam a na jednm miste a mam dojem, ze "vic > stejny" uz to ani byt nemuze, stejne obcas s koncim s tim, ze neco "podivne > nefunguje" a vyresi to kompletni preklad vseho co v mem repository mam a > nasledne reinstalace vseho co je nainstalovane na postizenem stroji. Ja to takto robim vzdy. Na vyhradenom jaile vzdy prekladam balicky "na zelenej luke” - vsetky balicky zmazem, potom prelozim z portov, potom vytvorim balicky. Na systemoch potom vzdy aktualizujem balicky pomocou pkg upgrade -f. Teda s reinstalaciou balickov aj ked sa nezmenila verzia. Prave z dovodu, ze obcas moze nieco podivne nefungovat. Uz som si takto par krat nabehol. Aj ked by mi to sposobovalo problemy iba raz za rok alebo raz za 3 roky, tak mi to za tie problemy nestoji. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: daily security run output, BYLO: pkg ako upratat chyby
Marek Soudny wrote: > ohledne daily security run outputu bych mel otazku. Resite nekdo > konsolidovany vystup z vice serveru? Je na to nejaky tool? > > Z par serveru se daily output da denne cist, ale z 20+ serveru uz to tak moc > zabavny ctivo neni. Stacil by mi 1 mail za vsechny, s vyctem problemu > (napriklad). To by ma tiez zaujimalo, ci nieco take existuje. Ja som si na to napisal vlastny skript. Cez procmail si tie maily ukladam do jedneho mailboxu a rano na nich spustim skript, ktory z toho urobi jeden mail. Spajam takto dohromady vsetky security/daily/weekly/montly run outputy, kazdy typ do zvlast mailu. Naviac servery, co maju identicky vystup zgrupujem. V periodic.conf mam nastavene (okrem ineho): daily_show_success="NO" daily_empty_output="NO" daily_status_security_inline="NO" Vystup je potom nieco take: Servers: harmony-sweb divine-sweb --- Checking for packages with security vulnerabilities: phpMyAdmin-php73-4.9.5 --- Servers: portbuild --- Checking for packages with security vulnerabilities: bind911-9.11.17: Tag: deprecated Value: End of life, please migrate to a newer version of BIND9 bind911-9.11.17: Tag: expiration_date Value: 2021-12-31 phpMyAdmin-php73-4.9.5 --- Keby niekoho ten skript zaujimal, tak mozem poskytnut. Ale je to v PHPku. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Stejná IP adresa v jailu - Address already in use
Zdravím, používám stejnou IP adresu pro host systém a pro jaily. Jaily používám na oddělení služeb, například apache a mysql. Nevím jestli je používání stejné IP adresy pro jaily podporované. Používá to někdo? Když jsem začínal s jailami, tak, jestli si správně pamatuji, v návodech bylo, že je možné použít sdílenou IP adresu, nebo pro každý jail vlastní IP adresu a NATovat. Ale teď o tom nemůžu nikde najít zmínku a všechny návody používají vlastní IP adresy. Ja to takto používám už dlouhou dobu a funguje to ok až na jeden problém. Občas (velmi zřídka) dostávám chybu připojení na databázi: Address already in use. Podařilo se mi to zreplikovat. Je to způsobené tím, že již existuje spojení na databázi v hostu z portu např. 4 na port 3306 a apache jail se snaží připojit na databázi ze stejného zdrojového portu. Při připojování systém vybere už obsazené číslo portu. Jail ale neví, že to číslo je obsazené (sockstat -4 ho nezobrazuje) a pak selže následné vytváření spojení, protože daná kombinace zdrojového a cílového portu a IP adresy již existuje. Neexistuje nějaká možnost povolit jailu, aby viděl i ostatní spojení jeho IP adresy, aby tento nešťastný výběr zdrojového portu nenastával? Jiná cesta, která mě napadla by bolo omezit výběr zdrojového portu. Například pomocí net.inet.ip.portrange. Jenže ten je sdílený - nejde nastavit pro jednotlivý jail jinak. Je tedy jediná správná cesta přejít na privátní IP adresy a port forwarding/NAT? Děkuji za odpovědi Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Stejná IP adresa v jailu - Address already in use
> On 10 Dec 2020, at 10:42, Dan Lukes wrote: >> Neexistuje nějaká možnost povolit jailu, aby viděl i ostatní spojení jeho IP >> adresy, aby tento nešťastný výběr zdrojového portu nenastával? > > Nevim o tom, ze by mira oddelenosti jailu byla az tak jemne konfigurovatelna. U jailů je možné nastavit několik allow.* omezení. Vím, že to tam není, ale psal jsem to pro případ, že něco přehlížím. Jinak kdyby ten výběr odchozího portu dělala nějaká rutina “níž v kernelu”, tak by mohla ten port vybrat volný. Protože pak to beztak selže někde “níž v kernelu”. Ale chápu, že když se to tak nemá používat, tak je to jedno. > Vnucuje se ale otazka - proc tam ten jail mas ? Ale nechci zadnou obecnou > odpoved "aby byly veci oddelene", protoze prave diskutujeme zruseni casti > toho oddeleni. > > Zajima me jakym konkretni rizika se pouzitim jailu pokousis omezit. Mohlo by > se uakzat, ze stejneho nebo podobneho vysledku lze dosahnout nejak jinak, bez > pouziti jailu. Treba chrootem ... Můj důvod je (bohužel právě) oddělení služeb a jednodušší správa. Chroot by pro některé služby byla možnost, ale kompletní systém/jail mi přijde jednodušší na správu a navíc chroot je pro jednu službu, ale často mám v jailu víc (souvisejících) služeb. Za jednu z výhod jailů považuji právě to oddělení. Když například aktualizuji balíčky a něco se pokazí, tak to odnese jenom ten jeden jail. > >> Je tedy jediná správná cesta přejít na privátní IP adresy a port >> forwarding/NAT? > > > Jestli jedinna to nevim, ale je to existujici funkcni cesta. Otazka je, v cem > ti nevyhovuje natolik, ze venujes cas hledani nejake jine. Jestli je správné použití jailů takové, že každý jail má mít svojí vyhrazenou IP adresu a jsem jediný, kdo to používá se sdílenou IP adresou, tak nemám problém to předělat na privátní IP adresy a NAT. Já si právě pamatuju (možná špatně), že když jsem s jaily začínal, tak se nabízely dvě možnosti - sdílená IP adresa nebo oddělená. A mně sdílená IP adresa nevadila a přišlo mi to jednodušší v tom, že tam není navíc další (stavová) vrstva s NATem. Navíc s ipfw je potřeba běžet natd a s pf (kde je to jednodušší) moc nekamarádím. Majo -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: cim vic jader CPU, tim pomalejsi
> host je FreeBSD 12.2-RELEASE-p5 Jen pro info, v posledním Quarterly Report je info o performance optimalizacích v pf: https://www.freebsd.org/news/status/report-2020-10-2020-12/#pf-performance-improvement Ale pro tento případ je to irelevantní, protože ty reviews jsou až po 12.2 release. Marián -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Obmedzenie portu 3306 cez firewall PF
Frantisek Hennel wrote: > Potreboval by som zablokovat pristup na mysql server (port > 3306), aby nebol pristupny do internetu a povolit by som chcel > tento port iba pre konkretne IP adresy, pripadne konkretne > subnety. Vsetky ostatne porty chcem ponechat normalne > otvorene, len ten jeden port 3306 chcem takto zablokovat. > > moj pf.conf vyzera nasledovne: > > table persist file "/etc/pf.blocked.ip.conf" > ext_if="em0" # interface connected to internet > block drop in log (all) quick on $ext_if from to any Na základe Tvojho konfigu by som to rozšíril takto: pass in quick on $ext_if from 10.1.1.0/24 to ($ext_if) port 3306 block drop in log (all) quick on $ext_if from any to ($ext_if) port 3306 pass povolí pakety. quick ukončí spracovanie pri zhode (takže pre subnet 10.1.1.0/24 sa už nebude pokračovať ďalším pravidlom) ($ext_if) vezme IP adresu/y na rozhraní. Zátvorky spôsobia update IP adresy v prípade zmeny IP adresy (v prípade používania DHCP na rozhraní). Zátvorky je možné odobrať, alebo tam dať konkrétnu IP adresu. block pravidlo zakáže všetkým ostatným prístup na port 3306. Je potreba, pretože maš default allow. PF nepoužívam primárne, ale keďže je ta otázka taká jednoduchá, tak som si dovolil odpovedať. Keď tak ešte počkaj na odpoveď niekoho viacej skúsenejšieho (s PF). Môže sa stať, že tam mám nejakú drobnú chybku. Ale myslím, že to takto v pohode pobeží. > Prosim o usmernenie aj v pripade, ak nie je mozne na tento > ucel pouzit firewall PF, aj ked urcite uprednostnujem prave > riesenie cez PF, kedze ho uz dlhsie pouzivam. Na tieto triviálne veci môžeš použiť ľubovoľný firewall. PF to samozrejme musí zvládať tiež. Marián -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Obmedzenie portu 3306 cez firewall PF
Frantisek Hennel wrote: > > Dakujem za pomoc, ale nefunguje mi to. > > pass in quick on $ext_if from 10.1.1.0/24 to ($ext_if) port 3306 > /etc/pf.conf:4: port only applies to tcp/udp Sorry, chýba tam "proto tcp”. pass in quick on $ext_if proto tcp from 10.1.1.0/24 to ($ext_if) port 3306 block drop in log (all) quick on $ext_if proto tcp from any to ($ext_if) port 3306 Alebo v jednom pravidle, ako to písal schrodinger: block drop in log (all) quick on $ext_if proto tcp from ! 10.1.1.0/24 to ($ext_if) port 3306 (alebo zjednodušene:) block in log quick on $ext_if proto tcp from ! 10.1.1.0/24 to any port 3306 Marián -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: binarni balicky
>> Ano, to je dobrá otázka a asi mi dala odpověď, kterou jsem nechtěl slyšet.
>> Repository mám výchozí, což je pro mojí 12.2 / armv7:
>> url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly";,
>> Prostým pohledem do http://pkg.freebsd.org/FreeBSD:12:armv7/quarterly/
>> zjišťuji, že poslední kvartál proběhl 2020-Dec-01
>> Takže asi mohu přejít na vlastní překlad, nebo se mohu pokusit přejít na
>> 13.0 RELEASE
>
> 13 ti nijak nepomuze, pro 13 je stejna verze balicku jako pro 12 i pro 14.
Proč by měla být verze balíčků pro 13 stejná jako pro 12 i pro 14?
To URL na balíčky obsahuje ${ABI} - kde je např. i 12, 13, 14. Takže stejné je
to pro 12.1 a 12.2, ale mělo (mohlo) by to být jiné pro 13.
Z toho příkladu z FreshPorts pro apache to i tak vypadá:
ABI latest quarterly
FreeBSD:12:armv72.4.35 2.4.46
FreeBSD:13:armv72.4.46 2.4.46_2
FreeBSD:14:armv72.4.46_2-
Quarterly verzre pro 13 je jiná jako pro 12 - 2.4.46_2 vs 2.4.46.
Vlastní balíčky na “FTP” jsem nekontroloval.
Majo
> Je dobre se podivat na tabulku na FreshPorts [1], kde jsou jednotlive verze
> pro jednotlive varianty vypsane a co je taky dulezite - koukat na Latest a na
> Quarterly, protoze to, ze je neco v ports tree (HEAD / main / current, nebo
> jak se to ted na Gitu jmenuje), jeste neznamena, ze je to backportovane do
> quarterly, kterou ty zrovna pouzivas ve svem pkg/repo/FreeBSD.conf
>
> [1] https://www.freshports.org/www/apache24/
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
Re: package db5
Tiež som sa divil, že to nefixli do expiráce. Ja si porty prekládam sám, tak som podporu db5 z apachu pred rokom vyhodil: Date: Sun Jul 17 10:42:05 2022 +0200 devel/apr1: Build without deprecated db5 Build apr1 without BDB support, because apr1 is built with deprecated db5 and FreeBSD folks didn't fix the issue for half a year even when db5 has now expired: db5-5.3.28_8: Tag: deprecated Value: EOLd, potential security issues, maybe use db18 instead db5-5.3.28_8: Tag: expiration_date Value: 2022-06-30 apr1 is used by apache24. Keď to tam stále ešte je expirované, tak je to smutné. Marián > On 19. 5. 2023, at 10:50, Jindrich Fucik wrote: > > Ahoj, > > na jednom novém stroji jsem zjistil, že apache24 stále používá apr, které je > kompilované s db5 a ta je už rok EOL (expiration_date Value: 2022-06-30) > > Stroj je poměrně malý a nechce se mi na něm skládat porty, abych si složil > devel/apr1 s podporou devel/db18 a nebo bed db podpory úplně. A tak si říkám, > to to za ten rok nikomu nevadilo? Dokonce i na fóru jsou na to téma staré > posty: > https://forums.freebsd.org/threads/the-db5-port-currently-does-not-have-a-maintainer.83937/ > > Nebo jsem něco přehlédl? > Díky > -- > FreeBSD mailing list (users-l@freebsd.cz) > http://www.freebsd.cz/listserv/listinfo/users-l -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Detekcia iba jedneho jadra na Supermicro E3-1240 v3
Ahoj, snazim sa nainstalovat FreeBSD na novy Supermicro server a mam problem, ze je detekovane iba jedno jadro. Server je osadeny procesorom Intel Xeon E3-1240 v3. Tento procesor by mal mat 4 jadra. V dmesg je toto: CPU: Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz (3392.23-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306c3 Family = 0x6 Model = 0x3c Stepping = 3 Features=0xbfebfbff Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800 AMD Features2=0x21 Standard Extended Features=0x2fbb TSC: P-state invariant, performance statistics real memory = 17196646400 (16400 MB) avail memory = 16487100416 (15723 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: FADT (revision 5) is longer than ACPI 2.0 version, truncating length 268 to 244 (20110527/tbfadt-320) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0x80d11010, 0) error 19 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 67, 1 (4) failed cpu0: on acpi0 cpu1: on acpi0 Detekovane je jedno jadro s dvoma vlaknami (cpu0, cpu1). Jedna sa o FreeBSD 9.2-RC4 amd64 s GENERIC jadrom. Na FreeBSD 9.1 sa to sprava rovnako. Neviete niekto poradit, co mozem skusit urobit, aby boli detekovane vsetky jadra? Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Detekcia iba jedneho jadra na Supermicro E3-1240 v3
Miroslav Lachman wrote: > Marián Černý wrote: >> snazim sa nainstalovat FreeBSD na novy Supermicro server a mam problem, ze >> je detekovane iba jedno jadro. Server je osadeny procesorom Intel Xeon >> E3-1240 v3. Tento procesor by mal mat 4 jadra. >> >> Neviete niekto poradit, co mozem skusit urobit, aby boli detekovane vsetky >> jadra? > > Co je to za motherboard? Zkusil bych se spis podivat po aktualizaci BIOSu. Vypatral som, ze sa jedna o Supermicro X10SLM-F. BIOS je tam v poslednej verzii 1.1a. Build Date je 08/20/2013. Nastavenia BIOSu su vychodzie (okrem poradia bootovania). V BIOSe su vsetky jadra povolene. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: [SOLVED] Detekcia iba jedneho jadra na Supermicro E3-1240 v3
Marián Černý wrote: > Miroslav Lachman wrote: > >>> snazim sa nainstalovat FreeBSD na novy Supermicro server a mam problem, ze >>> je detekovane iba jedno jadro. Server je osadeny procesorom Intel Xeon >>> E3-1240 v3. Tento procesor by mal mat 4 jadra. >>> >>> Neviete niekto poradit, co mozem skusit urobit, aby boli detekovane vsetky >>> jadra? >> >> Co je to za motherboard? Zkusil bych se spis podivat po aktualizaci BIOSu. > > Vypatral som, ze sa jedna o Supermicro X10SLM-F. BIOS je tam v poslednej > verzii 1.1a. Build Date je 08/20/2013. > > Nastavenia BIOSu su vychodzie (okrem poradia bootovania). V BIOSe su vsetky > jadra povolene. S problemom som sa obratil na Support Supermicro. Obratom poradili, ze mame skusit preflashovat BIOS, napriek tomu, ze tam bola posledna verzia, s tym, ze sa pri flashovani nastavi jumper JPME2 Manufacturing Mode Select. Nechal som teda BIOS preflashovat (jedna sa o dedikovany server) a system uz detekuje vsetky jadra: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Zmena spravania chmod na FreeBSD 9 (alebo ZFS)
Ahojte, vsimol som si zaujimave spravanie chmod-u na FreeBSD 9.2. Mam adresar log, ktory vlastni uzivatel1 a ma prava 777: drwxrwxrwx 2 uzivatel1 developers 4 Nov 4 11:05 log Ako uzivatel2 pustim prikaz "chmod 777 log". Predtym to prebehlo bez chyby (prava uz su 777, nesnazi sa menit prava, nevypise to chybu). Teraz to hlasi: chmod: log: Operation not permitted Je mi jasne, ze uzivatel2 nie je vlastnik, tak nemoze menit prava. Ale predtym to fungovalo (nesnazil sa menit prava). Naviac ked spustim ako uzivatel1 "chmod -vv 777 log", tak vidim, ze sa snazi menit prava, aj ked nedoslo k zmene: log: 040777 [drwxrwxrwx ] -> 040777 [drwxrwxrwx ] Netusite niekto, ci nedoslo vo FreeBSD 9 k tejto zmene spravania chmod-u? Na FreeBSD 7 a 8 to nerobi. Pripadne ci to nesposobuje ZFS, ten sme predtym tiez nepouzivali. Dakujem, Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Zmena spravania chmod na FreeBSD 9 (alebo ZFS)
Miroslav Lachman wrote:
>> vsimol som si zaujimave spravanie chmod-u na FreeBSD 9.2.
>
>> ze sa snazi menit prava, aj ked nedoslo k zmene:
>>
>> log: 040777 [drwxrwxrwx ] -> 040777 [drwxrwxrwx ]
>
> Nemam bohuzel nikde 9.2-RELEASE, mam tu na testovacich stroji 9.2-RC3 a
> 9.2-RC4 s UFS a tam to nedela.
> Zkusil jsem to same na starsim stroji (8.x) se ZFS a ani tam to nedela. Takze
> bych to prisuzoval kombinaci novy system + nova verze ZFS.
Tak som sa dopatral, ze za to asi mozu ACL.
% truss chmod 755 /var/log
...
stat("/var/log",{ mode=drwxr-xr-x ,inode=9,size=43,blksize=4096 }) = 0 (0x0)
pathconf("/var/log",0x40)= 1 (0x1)
chmod("/var/log",040755) ERR#1 'Operation not permitted'
...
% truss chmod 755 /mnt/test
...
stat("/mnt/test",{ mode=drwxr-xr-x ,inode=321024,size=512,blksize=32768 }) = 0
(0x0)
pathconf("/mnt/test",0x40) = 0 (0x0)
...
Prvy vypis je z ZFS, druhy z UFS. Na ZFS pathconf na otazku, ci system
podporuje _PC_ACL_NFS4 (0x40) dostane TRUE a potom vola chmod(). Na UFS
_PC_ACL_NFS4 vracia FALSE tak sa ten chmod nasledne nevola. Na FreeBSD 7.2 tam
to volanie pathconf() vobec nie je (asi tie ACL nepodporovalo). Mimochodom aj
ked som pustil "tunefs -a enable" na tom UFS filesysteme, tak ten pathconf()
vracia FALSE.
Netusite niekto, ci je mozne ACL na ZFS vypnut?
Marian
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
Re: Zmena spravania chmod na FreeBSD 9 (alebo ZFS)
Marián Černý wrote: > Mimochodom aj ked som pustil "tunefs -a enable" na tom UFS filesysteme, tak > ten pathconf() vracia FALSE. Ked sa pouzije "tunefs -N enable" na UFS, tak pathconf() pre _PC_ACL_NFS4 vracia TRUE pre a sprava sa to rovnako ako na ZFS - snazi sa volat chmod. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Zmena spravania chmod na FreeBSD 9 (alebo ZFS)
Cejka Rudolf wrote: Netusite niekto, ci je mozne ACL na ZFS vypnut? >> >> Zdá se, že to podstatné je v ZFS zadrátované, viz >> ... > > Z čehož mi vyplývá, že ACL u ZFS vypnout nejdou, nebo aspoň ne pro chmod > dostatečným způsobem, a že je to tak trochu vlastnost. Nešlo by to obejít > flagem -f, nebo má tato změna chování chmod hlubší důsledky? Dakujem za analyzu zdrojakov. Na ten chmod.c som sa na zaciatku dival, ale posledna vyznamnejsia zmena tam bola 4 roky dozadu, tak som nepredpokladal, ze by to mohlo byt tam. Nejedna sa o nic zasadne, len som bol zvedavy, preco sa to sprava inac, pretoze vsade kde som tom predtym skusal (FreeBSD 7 a 8, Linux, Mac), tak sa to spravalo inac. Jedna sa o maly deploy skript, ktory ma nastavene set -e (Exit immediately), nastavuje prava na adresare, premazava cache a pod. A ked to pusta iny developer, tak to teraz pada na tom nastavovani prav na zaciatku skriptu. Vyriesim to asi nejakymi podmienkami. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Update systemu
Jan Dušátko wrote: > 3 - Je mozne nejakym nastrojem provest kompilaci vsech nainstalovanych > balicku podle aktualni konfigurace do instalacnich binarek a ponechat je > stranou, aby se instalace dala provest v kratsim terminu? V tuto chvili mi > rekompilace zabira dost casu a mam zde problem s vyslednou dostupnosti > sluzeb Podobne ako Dan pouzivam jeden centralny server (jail), kde vytvaram balicky pomocou pkg. Na upgrade potom pouzivam pkg upgrade -f (nasledovany volitelnym pkg autoremove). Vlastny upgrade je rychly. Balicky vytvaram nasledovne: /etc/make.conf: WRKDIRPREFIX ?= /tmp/portbuild 0.clean.sh) rm -rf /tmp/portbuild 1.deinstall.sh) pkg delete -a -f 2.install.sh) cd /usr/ports/ports-mgmt/pkg && make install cd /usr/ports/www/apache24 && make install cd /usr/ports/lang/php5 && make install ... 3.repo.sh) cd /usr/ports/packages find . -type f -delete pkg create -a pkg repo . 4.clean.sh) rm -rf /tmp/portbuild Postup mi pride jednoduchy a spolahlivy (vsetko sa preklada od znovu). Aby servery vyuzivali takto pripravene balicky je potreba uz len vytovrit konfiguraciu v /usr/local/etc/pkg/repos (ja pouzivam pkg+http). Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Miniaturni cluster
Miroslav Prýmek wrote: > Dne 12. července 2014 14:26 Jan Dušátko napsal(a): >> Data se zalohuji po hodinach do snapshotu, vecer se necha jediny. Snapshoty >> jsou tyden zpet a potom ke kazdemu poslednimu v mesici za jeden rok zpet. >> Ostatni roky jsou jenom 31.12. > > Sorry za OT, ale existuje na tohle nejaky (uz hotovy)/standardni > skript, optiona do rc.conf nebo tak neco? Chci to zavest taky a proc > to psat, kdyz to uz muselo resit tisice lidi... Ja som nic take nenasiel, tak som si napisal vlastne skripty. Nie je to nic zlozite. https://gist.github.com/mariancerny/cbe7751c39910fb4abd0 Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: pkgng a lokální repozitář?
Martin Bily wrote:
> Potřebuji zůstat u vlastní kompilace balíčků na jediném stroji. Jako nadějná
> cesta se mi po zběžném průzkumu jeví výroba vlastního pkgng repozitáře s mými
> balíčky. Než se pustím do realizace, tak se chci optat: Řešili jste podobnou
> situaci? Také vlastní repozitář? Poudriere? (nemám dosud nastudováno)
Ja mam vlastny pkgng repozitar ale poudriere nepouzivam. Mam vyhradeny
portbuild jail, v ktorom si nainstalujem vsetky balicky (make install), ktore
potrebujem a na zaver pomocou prikazov:
cd /usr/ports/packages
find . -type f -delete
pkg create -a
pkg repo .
vytvorim pkgng repo, ktore nazdielam cez HTTP a na strojoch, kde chcem z neho
instalovat pridam konfiguraciu do /usr/local/etc/pkg/repos/ a zakazem FreeBSD
repo:
/usr/local/etc/pkg/repos/example.conf
example: {
url: "pkg+http://pkg.example.com:8085";
mirror_type: "srv"
}
/usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: { enabled: no }
Marian
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
Re: pkgng a lokální repozitář?
Dan Lukes wrote: > Me jde treba o tohle - k PHP5 existuje "podbalicek" tzsetup s databazi > svetovych casovych pasem (a zejmena udaji o prechodech na zimni/letni > cas). A mam server u jakesi letecke spolecnosti, ktera logicky potrebuje > mit tyhle informace spravne a aktualne. Ale fakt tam nemuzu upgradovat > cely PHP kdykoliv se objevi nova verze. Pkg umoznuje zamykat balicky pomocou `pkg lock`. Zamknuty balicek sa neaktualizuje. Myslim, ze by zafungovalo, keby sa pred aktualizaciou zamkli vsetky balicky okrem tzsetup. Marian -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Ako vybrat verziu SSL pre Apache
Dan Lukes wrote: > Jen, ze z hlediska stability systemu jako celku mam za pro sebe vhodnejsi > porty prekladat v prostredi co nejpodobnejsim tomu, na kterem nakonec pobezi Toto přesvědčení naprosto sdílím s Danem. Také si balíčky překládám všechny postupně skriptem jednoduše pomocí make install. Kromě toho, že mi to přijde spolehlivější, mi to přijde i jednodušší. Ale je pravda, že se snažím držet jenom jednu sadu balíčků (nepotřebuji nekompatibilní verze nebo jiné options). Co nejpodobnější pro mě navíc znamená, že (po zkušenostech) zásadně vždy upgraduju všechny balíčky (pomocí pkg upgrade -f). Bohužel poudriere začíná být už natolik oficiální, že někdy můj bug report s překladem balíčku odbijí s tím, že nepoužívám poudriere. Marián -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
