Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Aleš Rygl

Stran: 1 2 3 [4]
46
Hardware / Monitor HP Z32 vs Dell U3219Q
« kdy: 12. 11. 2018, 19:27:44 »
Dobrý den všem,

nemáte někdo osobní zkušenost se  4k monitorem HP Z32? Uvažuji o upgrade své pracovní stanice. Monitor jsem měl již velmi krátce možnost vyzkoušet (cca 15 minut), ale ne za všech podmínek. Jde mi například o homogenitu podsvícení a bleeding. Např. konkurenční Dell U3219Q s tím má prý docela velké problémy.

KDE ve 4k vypadá velmi hezky.

Díky
A.

47
Hardware / Re:Sparc Enterprise M3000 - jak využít?
« kdy: 11. 12. 2017, 13:43:42 »
U gentoo pisou 2.6.22-gentoo-r9 s excellent stability :) tak by to mozna byla taky cesta
https://wiki.gentoo.org/wiki/Sparc/Sun_hardware_compatibility_list
https://wiki.gentoo.org/wiki/Handbook:SPARC/Installation/Media#Hardware_requirements

No vida, Gentoo me teda nenapadlo.

Diky.
A.

48
Hardware / Sparc Enterprise M3000 - jak využít?
« kdy: 07. 12. 2017, 13:57:57 »
Ahoj,
dostaly se ke mě dva zánovní kousky Sparc Enterprise M3000 serverů. Jak je to teď se Solarisem, dá se ještě stáhnout a používat zdarma? Existuje nějaká OpenSource varianta operačního systému?
A.

49
Diky! Tohle zafungovalo. Bohuzel jsem tento postup nikde nedohledal a v dokumentaci jsem take zadnou zminku nenasel. Jeste jednou dekuji.
A.


50
To prave nefunguje:

Kód: [Vybrat]
31-Oct-2017 11:40:21.075 general: info: reloading configuration succeeded
31-Oct-2017 11:40:21.075 general: info: zone mojezona.cz/IN (signed): reconfiguring zone keys
31-Oct-2017 11:40:21.076 general: info: zone mojezona.cz/IN (signed): next key event: 31-Oct-2017 12:40:21.075
31-Oct-2017 11:40:21.078 general: info: reloading zones succeeded

Zona samotna take reloadnout nejde:
Kód: [Vybrat]
# rndc reload mojezona.cz
rndc: 'reload' failed: dynamic zone

V nepodepsane zone je serial 1509443810 a zona ma aktualne 1509443805. Nefunguje to, ani kdyz ma zona v souboru serial (unixtime) z budoucnosti. rndc sign zonu podepise, serial nastavi dle unixtime, ale nove zaznamy neprevezme.


51
Dobry den.
Nemate nekdo zkusenosti s automatickym DNSSEC v Bind9? DNSSEC mi funguje, po zavedeni zony, vygenerovani klicu se zona podepise. S kazdym dalsim podpisem se automaticky zvetsi serial, udela IXFR. Potud ok.

Konfigurace zony:

Kód: [Vybrat]
zone "mojezona.cz"
    { type master;
        file "master/db.mojezona.cz";
        key-directory "/var/cache/keys";
        inline-signing yes ;
        auto-dnssec maintain;
        update-policy local;
        serial-update-method unixtime;
};

Podle toho, co se pise na https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html
by si mel Bind9 trackovat nepodepsany zonovy soubor a v pripade, ze je v nem serial vetsi, nez je aktualni, pouzit ten a zvetsit jej. A doufal jsem, ze i pouzit tento zonovy soubor pro podpis. Bohuzel Bind9 zmeny v nepodepsanem souboru zcela ignoruje. Znamena to, ze je jedina moznost editace takove zony je pres utilitu nsupdate?

Diky.

A.





52
Zdravim,
mam autoritativni DNS pro nekolik desitek domen na Debianu. Server ve VMware, je to dedikovana virtualka(y) pro DNS server. Protoze jsem dve verze pozadu, tak bych chtel bych udelat cistou instalaci, i kdyz upgradovat bych mohl tez, jen si myslim, ze to bude rychlejsi.  Stavajici Bind9 bezi v chrootu, tak bych se chtel zeptat, jaky je (v tomto pripade) nazor na pouziti chrootu. Jestli to stoji za tu praci nebo se to "uz tak nedela". Server je v DMZ.

Diky za nazory
A.

53
Hardware / Re:Zálohování na pásku - pomalé LTO-2
« kdy: 28. 02. 2017, 10:07:31 »
1. radic se s paskou dohodl na dostatecne rychlosti?
2. zkusil jste pouzit primo tar pro ukladani na pasku s parametrem -b, napr. -b 1024?

Omlouvam se, koukam, ze uz jste to zkousel...

54
Hardware / Re:Zálohování na pásku - pomalé LTO-2
« kdy: 28. 02. 2017, 10:05:00 »
1. radic se s paskou dohodl na dostatecne rychlosti?
2. zkusil jste pouzit primo tar pro ukladani na pasku s parametrem -b, napr. -b 1024?


55
Server / Re:MariaDB/MySQL partitioning a diskové oddíly
« kdy: 16. 09. 2016, 13:56:01 »
Mas to na fyzickem zeleze nebo na nejake virtualizaci? VMware i Hyper-V umi tiered storage nativne.
Vyhodou pak je, ze presun dat HDD/SSD si ridi hypervisor a nejake zamykani tabulek pri presunu nehrozi.
Nevyhodou pak to, ze ani OS ani MariaDB nevi, ze pracuji s tiered storage a nemuzou sve zapisy nijak optimalizovat, coz by teoreticky mohly lepe nez hypervisor (ktery zas nevi co se vlastne zapisuje).

Je to fyzicke zelezo. O nativni podpore tiered storage v VMware a Hyper-V jsem nevedel, to je docela zajimave, Diky. Momentalne testuju variantu s tou SSD cache (lvmcache) a tedy nic moc. Schvalne jsem to udelal tak ze mam 200GB SSG cache a 2TB RAID5 na HDD. Read hit ratio je kolem 40% a write jen asi 6% a oboji stale klesa. Asi je to tim mym specifickym druhem zateze.

56
Server / Re:MariaDB/MySQL partitioning a diskové oddíly
« kdy: 15. 09. 2016, 12:03:16 »
Diky vsem za tipy. Prostuduji. O btier/lessfs jsem cetl, ale prijde mi, ze to umrelo.

57
Server / Re:MariaDB/MySQL partitioning a diskové oddíly
« kdy: 15. 09. 2016, 10:38:38 »
Nevim, jestli si uplne rozumime. Hodilo by se mi neco, co nejak spoji obe pole  do jednoho tak, jako to delaji enterprise class uloziste pod oznacenim "Automated tiered storage". Horka data se pak udrzuji na SSD, ostatni na HDD. Presun velkeho baliku dat mezi poli v ramci serveru neni tak zle, sekvencni cleni a zapis (HDD) je kolem  400MB/s. Problem je, ze pokud to dela databaze (neni to obycejne kopirovani), je to problem, krom pomalosti se cela partitionovana tabulka zamkne.

58
Server / MariaDB/MySQL partitioning a diskové oddíly
« kdy: 14. 09. 2016, 19:15:04 »
Zravím,

sháním nějaký tip nebo radu ohledně partitioningu v MariaDB vs. diskové oddíly na na serveru. Mám DB s jednoduchými shodnými tabulkami, do které denně přibude cca 20 milionu řádků. Za den je to podle použitého engine cca 43GiB (InnoDB), 17 GiB (InnoDB compressed), 18.5GiB (Aria) dat. Během práce DB vzniká cca 30 GiB dat binárních logů za hodinu - masivně se updatuje a insertuje jedna z tabulek.
Na serveru HP DL380 G9 mam 4x 400GB SSD a 4x 900GB HDD na P440 Smart Array, server ma 256GB RAM. Hledám optimální způsob využití diskového prostoru. Zatím mam range partitioning po dnech spolu se subpartitions podle key. To samo o sobě funguje dobře. Stačí každý den vytvořit novou partition a dropnout staré. Momentálně jsou SSD disky v RAID 1+0, což dělá cca 716 GiB místa pro data a logy databáze. HDD mám také RAID1+0.
Potřeboval bych nějak využít volný prostor na SSD a HDD tak, aby ideálně partitions se starými daty byly na HDD a nově vznikajicí na SSD. Při definici partitions se dá říct, kde data fyzicky budou, ale změnit to po naplnění partition jde jen za cenu přesunu dat a to trvá i hodinu. MySQL umí v posledních verzích general tablespaces, ale přesun dat mezi nimi je jak se zdá také za cenu rebuildu partition. Což dost nasazení partitioningu v mém případě dost omezuje.
Zatím nejnadějnější se mi jeví nasadit lvmcache. Část SSD kapacity použil jako tu cache pro HDD RAID a zbytek pro binární logy DB. Ale je to tak trochu skoda tech SSD. Ve finále by DB měly být dvě a měla by mezi nimi běžet Master-Slave replikace.

Nečekám řešení, potřeboval bych spíš nasměrovat, pokud někdo zkušenější něco podobného řešil.
A.

59
Sítě / Re:Dial-up cez smartfon
« kdy: 05. 09. 2016, 12:39:17 »
A co HD Voice ;) Jinak napr. u T-Mobile je CSD pristup opravdu nekolik let vypnuty. Sice to obnaselo jen jeden maly router s E1 do ustredny, ale i tak se to zrusilo. Schvalne si vytocte 603124927.

60
Pokud je heslo jediny atribut, ktery ma uzivatel v LDAPu moznost menit, mozna by stacilo vycist tzv. operational  attributes jeho rekordu. Je mezi nimi i modifiersName a modifyTimestamp. Ldapsearchem to udelate pomoci parametru "+"

Stran: 1 2 3 [4]