Příspěvky

1171

Server / Re:Jak zavřít porty na firewallu

« kdy: 11. 03. 2018, 21:56:36 »

Fail2ban si IMO zobe data z logu SSH, Cyrus IMAP/POP a patrně spousty dalších věcí (běžné varianty ftpd...)
Zbaví vás otravných robotických útoků hrubou silou, kdy zombie botnet zkouší různá hesla (pomalý slovníkový útok + k tomu pár kombinací čísílek apod.) Je to užitečné v situacích kdy hrozí u lokálních uživatelů slabá hesla, a přitom potřebujete nechat konkrétní službu otevřenou z celého světa. Pokud máte na stroji účet jenom sám, a máte silné heslo, tak už fail2ban velkou výhodu nepřinese...
Přesun SSH na jiný port není špatný nápad, vyloučíte tím otrapy kteří zkouší známé starší díry v SSH (zas tolik jich není) a nedají si tu práci, najít SSH na nestandardním portu.

Nevím o distribuci, kde by byl fail2ban nainstalovaný v základu. Ne že bych to zkoumal. V Debianu kde jsem ho chtěl, musel jsem si ho sám doinstalovat. Tušímže stačilo ze standardního balíčku.

Potřebujete především zabránit napadení počítače zvenčí. Tzn. zafiltrovat především input.
Jak se Vám někdo dostane dovnitř, tak už je docela krátká cesta k tomu, aby se dostal k rootovským právům, a pak Vám nějakých pár pravidel v iptables stejně nepomůže.
Ale v zásadě Vám jistě nic nebrání dát si "-P drop" i na output a povolit si směrem ven jenom služby co fakt potřebujete k užitečnému provozu. Zbavíte se tím zneužití jednotlivých služeb jako "reflektorů" v případech, kdy útočník nezískal systém plně pod svou kontrolu. Patrně bych relace směrem ven filtroval podle cílového portu, tzn. na jaké porty to chodí ven. Z lokálu ven se totiž všechna spojení otvírají se zdrojovým portem dynamickým, 1024 a výš... to neofiltrujete. Jako první věc bych povolil asi DNS - tzn. především UDP na port 53. (Zrovna to DNS možná používá 53 i jako lokální/zdrojový port, nejsem si jistý.) Hloupé je, že i tak ten filtr v outputu bude dost široký - a každá díra, kterou otevřete, bude použitelná pro spáchání DoS na někoho dalšího na dotyčnou službu.

Nakonec souhlasím s předřečníky, že je třeba se zaměřit na specifické zabezpečení služeb, které potřebujete nechat otevřené do světa. Aby neměly v konfiguraci trapné přehmaty (známé díry).

Loopback device není nějakým "principem" těch pár příkazů co jsem poslal. Je to IP rozhraní, které se používá pro lokální IP komunikaci v rámci jediného stroje. (Pro software, který není natolik pokročilý, aby pro lokální komunikaci použil lokální rouru / filesystem socket, nebo nějaké alternativní mechanismy.) Nemá valného smyslu, filtrovat si provoz v rámci jediného stroje.

Těch pár řádek co jsem poslal... prostě jsem zkopíroval holý základ ze své starší tvorby. A naučil jsem se to před lety z nějakých tutoriálů od Rustyho Russela, které byly původně pro IPchains (ještě před netfilterem/iptables). Popravdě takhle na jednom stroji to je pohoda. Trochu se to zkomplikuje, když má ten stroj forwardovat traffic mezi dvěma sítěmi, případně NATovat atd. A co teprve když Vám roste počet rozhraní. A proč syrové IPtables? Snažím se vidět přesně co dělám. Postupem času zjišťuju, že je to asi porucha ze stejného soudku jako perpeťáctví, protože člověk nemůže umět všechno... Prostě jsem se to kdysi naučil, tak to používám. IPtables nejsou složité. Osobně mi přijdou složitější na pochopení různé "zjednodušující" uživatelsky přítulné nadstavby :-( protože nevím, co přesně dělají. Dokud se nepodívám přes iptables -L .

1172

Sítě / Re:Pomalá síť a nic na firewallech

« kdy: 11. 03. 2018, 21:08:14 »

K téhle debatě jsem se přitočil trochu pozdě, ale možná to pomůže někomu dalšímu...

Asi nejdůležitější poznatek zní:
o problému nelze konkrétněji debatovat bez konkrétních údajů. Velmi konkrétních.
Topologie sítě, přinejmenším té co máte sami pod palcem,
struktura softwarového řešení které nad tou sítí běží.
Chápu, že toto z principu nemůžete ventilovat ve veřejném debatním kroužku.

Říkáte, že máte pronajatý dark fiber, a zároveň zmiňujete, že to může být kdesi v MPLS levelu?
Slyšel jsem, že se over IP (skrz MPLS) dá transportovat dneska už i SDHčko, ale tmavé vlákno ani lambdu jaksi z principu snad ne :-) Trochu si z Vás utahuju - chci říct, že nelze smíchat jabka a hrušky z několika vrstev a chtít po lidech ve fóru, aby něco od stolu poradili.

Vážně dost srandy:
Aplikujte obecný postup pro hledání závad v topologii. Jestli začnete od konců, nebo odspoda, to je jedno - prostě odněkud. Vyhrnout si rukávy a do toho. Najděte si místo, kam připojíte odposlechovou sondu, a nahrávejte. Neukázal jste ani traceroute. Jsou po cestě nějaké firewally / proxiny skrz které traceroute neproleze? Nebo jenom holé routery? Sem tam nějaký paketový filtr? Je v cestě nějaká VPN technologie? Pokud jsou tam firewally, kolik jich je za sebou? Jak moc krutopřísně jsou zafiltrované? Hrozí po cestě application-level proxy pro konkrétní použité protokoly? A jsem u toho zpátky - pokud mluvíte o pronajatém holém vlákně, tak se asi nebavíme o firewallech? Nebo se to dá chápat tak, že Vám vede mezi lokalitami holé vlákno, ale dodavatel infrastruktury "as a service" si nad tím jede nějaký svůj vlastní obláček, do kterého nevidíte?

Svou sondu můžete vřadit klidně do holého vlákna - pokud si naplánujete výpadek a "poskytovatel as-a-service" Vás k tomu pustí. Pokud nezní zdravě, odposlouchávat to switchem s mirrorovým portem (třeba protože RSTP to pozná a konverguje v desítkách vteřin), existují fiber tapy.
https://www.garlandtechnology.com/products/passive-fiber-network-taps
Nějakých 600 EURO za zcela pasivní duplexní optický odposlech není takový ranec ve srovnání s tím, kolik času jsou bílí límečci schopni strávit vzájemným přesvědčováním v hromadných mailech.

Podobně se dá odposlouchávat metalika - koupíte sice spíš forwardující aktivní tap,
https://www.garlandtechnology.com/products/copper-network-taps
pasivní jsem si musel ubastlit, a zcela pasivně lze odposlechnout jenom 10/100, nikoli gigabit... asi proto jsou metalické tapy většinou forwardující. Ale neměly by drbat do provozu, jenom přidají trochu zpoždění.

Kolik dat Vám tam teče? Na jaké rychlosti to provozujete? Do 1 Gbps to není moc velký problém. Grabovat 10Gbps tak abyste neztrácel pakety, to už chce trochu slušné vybavení.

Ve větší firmě jsem kdysi dělal a chápu, že pokud máte všechno "as a service", tak běžně nemáte po kapsách zbytečný počítač se dvěma optickými síťovkami. Nad tím mohu jenom pokrčit rameny.

Odhaduji, že v dnešní době na holém vlákně nebo lambdě máte Ethernet. Na to stačí wireshark. Odhadem i kdyby tam v IP bylo vmezeřené ještě MPLS, podle mého to Wireshark zvládne dissectovat. A jakmile máte capture, můžete především sledovat TCP relaci a Wireshark sám zvýrazní retransmise = ztracené pakety. Vybavuju si, že jsem docela úspěšně koukal Wiresharkem i na databázovou relaci (MSSQL) - sice jsem neměl dissector/analyzátor, ale v surových datech byly vidět z jedné strany SQL dotazy a z druhé strany data, a podle časových značek šlo docela dobře poznat rozestup mezi dotazem a odpovědí. Na koleně, ale dalo se. (Lepší by bylo nějaké statistické vyhodnocení latence dotaz/odpověď, ale to chce protokolově specifický analyzátor.) Toto provést na dvou koncích té komunikace. A nejlíp třeba porovnat, jak funguje "klient" lokálně v rámci LAN poblíž serveru, ve srovnání s provozem skrz WAN infrastrukturu.

Kromě wiresharku lze přímo z koncových zařízení ledacos zjistit pingem, nebo třeba FTP klientem. Záleží jistě na kapacitě... v dávných dobách bylo na FTP se zapnutým hashováním na VGA konzoli hezky vidět, když jel přenos maximem co dala linka, vs. když se zadrhával kvůli ztraceným paketům - ať už to bylo přetížením, rate-limitem po cestě, nebo třeba špatně nastaveným duplexem. V jednoduchosti je síla. Ping nekecá. A když zkusíte třeba různé délky paketů, možná najdete na round-trip zpoždění a ztrátovosti nějaký zlom či jinou anomálii.

Hloupé je, pokud firewall třeba pustí ping/traceroute skrz, ale vybrané služby odklání do inteligentních filtrů/keší/překladů... pak nemá test pingem moc velkou vypovídací hodnotu.

A při sniffování odposlechovou sondou trochu zkazí náladu, když je payload zavřený v nějaké šifrované VPNce. No aspoň se pak dá odhadnout MTU a případné na něj navázané nectnosti.

Klasický problém u VPNek je MTU pronajaté transportní sítě vs. MTU payloadu, z toho plynoucí fragmentace, a když třeba řešitel firewallu (resp. admin některého z routerů po cestě) nevhodně zařízne "ICMP couldn't fragment", tak je o zábavu postaráno. Pokud klient pořád dokola navazuje TCP relace, a na každé z nich musí proběhnout PMTU black-hole detection, tak to "trochu" zdržuje.
Ale pokud máte pronajatá holá vlákna, tak asi není problém trochu zvednout "vnější" MTU na fyzických rozhraních, nádobíčko na MPLS VPN (pokud se Vás týká) už asi na MTU taky není skoupé, takže k fragmentaci ani nemusí docházet...

Pokud máte v cestě firewall (firewally) tak se skutečně můžou dít věci. Softwarové zpracování provozu, proprietární vychytávky výrobce FW... je to svět sám pro sebe.

Jednou z vlastností WAN linek je vyšší latence oproti LAN. Zejm. pokud provoz prochází nějakým šifrujícím zařízení (VPN tunel endpointy). Různé druhy provozu jsou na latence různě háklivé, ve smyslu subjektivního uživatelského dojmu. Třeba pokud je na jedné lokalitě DB a aplikační server s HTTP rozhraním, a klienti za WAN spojem mají jenom browser, tak naservírovat uživateli stránku přes rychlou WAN není problém, protože se uplatní TCP window (nečeká se na potvrzení každého paketu zvlášť). Ale pokud je na jedné lokalitě DB a "aplikační" část leze do té DB z jiné lokality skrz WAN, a nejlíp chrlí větší počet SQL dotazů, které navíc serializuje, třeba detailní formulář přes celou obrazovku co tahá milion číselníků v jednom vlákně, to už může uživatel pociťovat jako zdržování. Přitom procesory na obou stranách se flákají, disky na serveru se flákají, síť se fláká, pakety se neztrácejí, ale prostě těch transakcí dotaz/odpověď je na jeden formulář tolik, že už pocítíte rozdíl mezi 100 us v rámci LAN vs. 5-10 ms v rámci rychlé WAN (round-trip jedné transakce).

V zásadě pokud Vás "poskytovatel řešení" nepustí čenichat na páteřních linkách = dark fiberu (nebo tam není nic moc k vidění), velmi dobrou vypovídací hodnotu má záznam provozu pořízený na předávacích bodech, tzn. co Vám skutečně leze ven z "LAN+WAN solution as a service" ke koncovým počítačům. Dá se pořídit záznam wiresharkem a nějak se v něm nimrat/analyzovat, nebo třeba pořídit v průběhu prime time video-záznam chování softwaru na klientu 1) v LANce pohromadě se serverem a 2) na jiné lokalitě skrz WAN. Prostě to nějak zdokumentovat. Pokud z toho vyplyne jednoznačný rozdíl, tak ať se solution provider kouká snažit, nebo poletí i se SLAčkem.

Taky se vám ale může stát, že zjistíte chybu na své straně, resp. na koncových bodech. Mě třeba dost nemile překvapilo, že sedmičkám a desítkám už v podstatě nestačí 4 GB RAM na provoz bez swapování (hint: sedmičky měly resmon.exe ještě samostatný, v desítkách je na něj odkaz ze správce procesů). Upgrade na 8 GB znamená zásadní rozdíl. A taky není špatné koukat po očku do resmonu, "co to zase štrachá diskem" (nebo co to sežralo celý procesor) - obvyklých podezřelých je v moderních windowsech několik. Tolik ke klientovi. Přetížení na straně serveru je třeba také vyloučit, než se budete mračit na dodavatele síťového řešení. Opět nejsnáz porovnáním A/B (blízko u serveru vs. skrz WAN).

A jsem zpátky u toho: je potřeba především zvednout kapotu a snažit se něco změřit. Dokud se nepodíváte, tak jenom věštíte. Teprve když se podíváte, tak třeba něco zjistíte. Já třeba většinou zjistím "nene, tady problém není". A občas mi naopak pěkně klesne čelist :-) Osobně se snažím, než zcela vážně otravuju dodavatele, mít napřed "zameteno před vlastním prahem" = umět problém přesně specifikovat na předávacím bodě. A dost často při tom úklidu na vlastním prahu zjistím problém na své straně - a dodavatele pak už ani neotravuju.

Nemusíte zrovna nacvičovat složitou akrobacii s wiresharkem, které nebudou rozumět ani technici Vašeho dodavatele. Jak už jsem navrhl výše, třeba jenom pořiďte krátký videozáznam desktopu "lokálně" a "skrz WAN". A dejte si záležet, když srovnáváte A vs. B, ať neporušíte princip "za jinak stejných okolností" = nejlépe v tomtéž čase a ať mají oba klienti tentýž HW a OS (nebo hodně podobný). Přesněji řečeno, pokud chcete prokázat problém v síti, tak ať je testovací klient v obou případech pokud možno nabušený, aby ani náhodou nemohl být úzkým hrdlem.

1173

Server / Re:Jak zavřít porty na firewallu

« kdy: 10. 03. 2018, 21:11:49 »

Ještě holýma rukama v IPtables:

vypsat aktuální pravidla

Kód: [Vybrat]

iptables -L

smazat všechna aktuální pravidla (flush) - pouze v hlavní tabulce, ale nat ani mangle asi zatím používat nebudete

Kód: [Vybrat]

iptables -F

default pro chain "input" ať je drop

Kód: [Vybrat]

iptables -P INPUT DROP

default pro chain "output" by mohl být accept?

Kód: [Vybrat]

iptables -P OUTPUT ACCEPT

povolit cokoli z interního IP loopbacku

Kód: [Vybrat]

sudo iptables -A INPUT -i lo -j ACCEPT

povolit traffic směrem dovnitř, který souvisí s relacemi které jsme sami navázali směrem ven:

Kód: [Vybrat]

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

nebo

Kód: [Vybrat]

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

V tomto stavu by měly chodit interní služby přes loopback, plus byste se měl dostat všude ven, ale nikdo se nedostane k Vám dovnitř.

Příklad: povolíme port 80 směrem dovnitř:

Kód: [Vybrat]

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Příklad: povolíme port 22 směrem dovnitř:

Kód: [Vybrat]

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Příklad: povolíme ping směrem dovnitř

Kód: [Vybrat]

iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT

Je to jenom naprostý základ, ale na to jste se ptal.
Nehrozí, že Vám prostě uhodli hrubou silou (automatem) heslo na SSH?
Pokud ho potřebujete otevřené zvenčí, zvažte fail2ban.
Jak už tu někdo psal... pokud někdo využil díru v HTTPd nebo tak něčem,
co potřebujete mít otevřené do světa, tak Vám packet-level firewall nemusí
postačit.

https://www.docum.org/docum.org/kptd/
https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands
https://linux.die.net/man/8/iptables

1174

Hardware / Re:Mám vyměnit baterii u UPS Eaton?

« kdy: 08. 03. 2018, 17:44:54 »

Jsem se rozhodl to vyměnit a objednal za pětistovku novou

Tak proč se vlastně ptáš? 

Moje UPSka si zařvala, když baterka zeslábla a bylo to po asi 5 letech.

Jo souhlas, mě jednou vydržely baterky v UPS asi 7 let. Už nevím jestli Panasonic nebo Yuasa. Fakt je že pak už byly tak nafouklé, že byl problém dostat je ven. Mohli bychom plynule navázat flame warem ohledně oblíbených značek baterií, co říkáte...

1175

Windows a jiné systémy / Re:Synchronizace času doménových klientů

« kdy: 08. 03. 2018, 11:00:57 »

Grammar nazi poznámka:

"pool" [vyslov "půůůl"] znamená bazén, množina, kyblík něčeho předpřipraveného. Případně je to k vidění jako sloveso: něco si předem připravit / nahromadit / dlouhodobě průběžně společnými silami udržovat na hromadě pro sdílené použití. V našem případě množina NTP serverů od které chceme, aby nám vybrala nějaký náhodný server, kterého se máme ptát. (Třeba europalety se taky točí v nějakém sdíleném "poolu".)

"to poll" [vyslov "pollll"] znamená dotázat se. Klasicky přečíst jednorázově nějakou hodnotu z hardwaru. Nebo v tomto případě poslat dotaz upstream NTP serveru / vyžádat si od něj aktuální přesný čas. ("Opinion poll" je průzkum veřejného mínění.)

Odtud vysvětlivka k věci:

Poll interval = jak často se dotazovat.

Minpoll / maxpoll = v jakém rozmezí se má pohybovat poll interval. Přesněji, v případě ntpd se jedná o exponent v mocnině dvou. Takže "minpoll 6" znamená dotazuj se v intervalu ne kratším než 2^6=64 sekund. Reálně se ntpd ptá v intervalu pseudonáhodně zvoleném mezi 2^minpoll až 2^maxpoll [sekund].
http://doc.ntp.org/4.1.1/confopt.htm
Zda mají tyto pojmy shodný význam a datový typ v konfiguraci w32time, to nevím :-)

1176

Vývoj / Re:Přehlednost syntaxe C++

« kdy: 08. 03. 2018, 06:52:56 »

Děkuji za zmínku o boost::recursive_wrapper . Zrovna asi předevčírem jsem naznal, že něco takového nevyhnutně potřebuju (zacyklit několik šablon, aby na sebe navzájem odkazovaly) a že v C++ je to normálním způsobem ilegální. I zmastil jsem si takovou věc jednoúčelově na koleně (někde něco jsem obalil do obyčejné třídy, na kterou se dá udělat forward deklarace). Teď vím, že je na to šablona :-D

1177

Vývoj / Re:Jakou vybrat technologii pro eshop?

« kdy: 07. 03. 2018, 21:48:09 »

...spousta řečí o i6...

v čem je to lepší než Odoo?

Omlouvám se, odpovědí neposloužím, neb Odoo neznám :-)

Kouknul jsem na nějaké video-intro namátkou o modulu "sklad" v Odoo a uznale jsem přikyvoval, že mají věci které znám z i6. A je tam spousta modulů, které už podle názvu odpovídají spíš velkému ERP. Docela by mě zajímala vnitřní architektura toho softwaru. Jak moc je to vrstevnaté, jak na sebe jednotlivé moduly vážou.

V čem bych čekal takové banální zádrhele: jak moc Odoo pasuje na naši legislativu a obecně prostředí. Loadnout firmu z Justice podle IČO nebo názvu, ověření DIČ, kontrolní hlášení k DPH, import kurzů z ČNB, tisk expedičních štítků pro tuzemské balíkové dopravce apod. Nemám v malíčku účetnictví, ale třeba v účetní osnově a postupech bych taky čekal nějaká lokální specifika. Umí to vůbec česky? Myslím aby s tím dokázali fungovat interní uživatelé. Apod.

1178

Windows a jiné systémy / Re:Synchronizace času doménových klientů

« kdy: 07. 03. 2018, 21:26:34 »

To funguje, s výjimkou těch virtualizovaných DC. Fakt je potřeba to tam vypnout, jinak to zhusta rozjebe synchronizaci v celé doméně.

Učinil jsem tak, klienti jsou synchronizovaní, čas drží přesně
Jen by mě ještě zajímalo jak často si klient čmuchne k DC serveru pro čas, je to průběžně nebo jen při loginu?

Nedokážu najít v dokumentaci, zda to tak skutečně je, ale tipuji, že je blbost, aby w32time fungovala jenom při přihlášeném desktopu. Jsem si skoro jistý, že to funguje i ve stavu "žádný uživatel není přihlášený", pokud je daný stroj přiřazen v AD do domény. Technicky to dává velmi dobrý smysl.

Možná napoví následující úryvek z Vašeho výpisu:

w32tm /query /status
Last Successful Sync Time: 3/6/2018 10:09:33 AM
Poll Interval: 10 (1024s)

Nechte stroj nějakou dobu běžet bez přihlášeného uživatele, pak se přihlaste a zeptejte se uvedeným způsobem.

Není mi jasné, zda ten "poll interval" je pevný. V případě ntpd (parametry minpoll/maxpoll) je perioda dotazování v nějakém rozmezí pseudonáhodná.

Potkal jsem nějaká starší povídání o volbě zdroje času v rozsáhlejší konfiguraci domén (domain forest).
https://tigermatt.wordpress.com/2009/08/01/windows-time-for-active-directory/
https://blogs.msdn.microsoft.com/w32time/2007/09/04/keeping-the-domain-on-time/
Nevím kolik z toho je ještě dneska pravda. Např. jsem žil v domnění že w32time používá NTP i v rámci domény - ale uvedené zdroje mluví o microsoftím vlastním mechanismu NT5DS.

1179

Windows a jiné systémy / Re:Synchronizace času doménových klientů

« kdy: 07. 03. 2018, 18:04:04 »

@ZAJDAN: optimální pro DC (z hlediska servírování času) je běžet na holém železe.

Pokud správně chápu bod č.5 a ještě čerstvé osobní potvrzení od Lol Phirae, tak pokud DC musí běžet ve virtuálu, je v tomto specifickém případě vhodné, aby si řešil časomíru sám = DC ve virtuálu si sám bere upstream NTP z divokého internetu a servíruje dál doménovým klientům, na čas od HV (hostitele) kašle a je úkolem HV, aby guestovi časomíru pokud možno nemrvil přerušováním přiděleného procesorového času a rozhasením timer interruptu (což patrně konfiguračně neovlivníte).

Varianta, že DC ve virtuálu si bere čas od HV=hostitele, podle uvedených zdrojů reálně nefunguje. Je to ale specifický případ MS DC. Obecná rada je přesně opačná :-(

Slýchal jsem, že tik a tak jsou docela vytížení. Nevím zda W32time vezme pool.ntp.org = DNS round-robin load-balanced množina NTP serverů rozprostřená po zeměkouli. Pokud chcete jistotu, znamená to postavit nebo koupit 1-2 dedicated stratum 1 servery zavěšené na GPS (o fous horší varianta je DCF77). Se třemi a více NTP servery je to teoreticky odolné dokonce i proti manipulaci jednotlivého NTP serveru (outlier rejection).

1180

Vývoj / Re:Jakou vybrat technologii pro eshop?

« kdy: 07. 03. 2018, 13:30:36 »

Třeba i6 má v sobě už tolik užitečné business logiky a rozumných datových modelů...

To je presne to, co 99% lidi nechce. Firma ma nejaky svoje ERPcko/ucetnicvi/sklad/.... a shop chce napojit prave na to. Coz je duvod proc je lepsi to napsat od nuly, protoze netreba vymejset jak to naroubovat na nejaky kravoviny, o kterych si tvurce toho hotovyho myslel, jak sou uzasny.

Tohle sem zazil doslova in natura, s jistou "nejvetsi dodavatel shopu" firmou netdirect. Zakaznik chtel shop napojenej na svy systemy, a oni "hotovy" dilo zacli predavat s "no a tady si zadate kartu zbozi".

Nevím jestli "většina lidí", ale jinak tesat do kamene. Je samozřejmě blbost snažit se poskládat dva softwarové balíky, které mají každý svůj datový model a značný vzájemný překryv funkčnosti. Pokud má někdo ve fabrice SAP nebo jiný velký ERP balík, hledáte nejspíš lehoučký e-shop, který k tomu půjde s malým úsilím přiintegrovat. I tak bych koukal po něčem "předem přizpůsobeném" dané značce ERP, aby se potlačila tvorba kočkopsa.

Ale pokud je situace taková, že má někdo jakési klasické malé účto bez e-shopu, a s nevalnou možností něco navenek integrovat, pak může být "all in one" řešení jako i6 tou správnou cestou kupředu. Potkal jsem firmy, které na podobnou práci (malá obchodní firma, jenom sklad s e-shopem) používají K2 - s tímto softwarem nemám zkušenosti. Koukám že jak i6 tak K2 samy sebe označují jako ERP... no je to už dávno, co nám o ERP povídali ve škole :-)

1181

Vývoj / Re:Jakou vybrat technologii pro eshop?

« kdy: 07. 03. 2018, 11:34:01 »

Třeba i6 má v sobě už tolik užitečné business logiky a rozumných datových modelů, že ji těžko někdo dožene tvorbou "na zelené louce". A to říkám jako člověk, který jakožto "admin z nouze" skřípe zubama nad MSSQL a obecně nad závislostí na MS. Neznám přesně cybersoftí business model, ale vcelku bych se nedivil, kdyby dokázali instanci i6 pronajmout někde "na obláčku" - instanci databáze a aplikace pro další firmu to umí, připojit na to virtuální webík to umí, dovedu si představit že k tomu pronajmou i virtuálek pro tlustého klienta někde poblíž SQL serveru (nebo RDP/RDS desktop).

Uz je to vic jak 15 let co jsem I6 videl naposledy, ale neni on to spis ERP? Tazatel shanel e-shop.....

i6 bych jako ERP neoznačil. Je pravda, že asi nemáme všechny moduly, co se do toho dají koupit, takže bych se nerad dopustil dezinformace.

Z našeho pohledu i6 je "vše v jednom" pro firmu na šoupání krabic s e-shopem. Používá/používala to velká část distributorů PC komponent. Umí to evidovat produkty, zákazníky/dodavatele, nabídky/objednávky (tyto oběma směry), expedice, fakturace, platby, reklamace, plus spoustu dalších věcí o kterých ani nevím. Umí to účtovat v rámci naší legislativy, umí to více měn, umí to tisknout doklady ve více jazycích. Má to integrovaný e-shop! Naše vedení se zpočátku snažilo, nechat si k tomu externě napsat vlastní webové rozhraní, ale během pár měsíců to skončilo u integrovaného e-shopu (k mé velké úlevě) a od té doby se jenom asi dvakrát zásadněji aktualizoval "kabátek", spíš z PR důvodů než že by na starší/tradiční podobě bylo něco špatně z hlediska funkčně-technického. Leze se do toho buď skrz HTTP rozhraní (e-shop) nebo skrz tlustého nativního klienta pod Windows. Škoda že je to tak závislé na Microsoftu - ale srovnatelné RAD prostředí asi není jinde k dispozici.

Zavedení v našem případě proběhlo v zásadě "na první dobrou". Asi měsíc se na tom šéf učil v demo provozu, zároveň s "přípravou infrastruktury". Prakticky celý prosinec. Od 1.1.2005 jsme najeli ostrý provoz a během asi týdne klíčoví lidi uměli základ co potřebovali. Prakticky se nezadrhnul provoz (obchod). Samozřejmě různé finesy jsme objevovali a ladili postupně (objevujeme a ladíme průběžně dodnes). Nejsme velká firma, naše interní procesy proto nejsou moc zašmodrchané a jejich implementace v i6 nám převážně vyhovuje.

i6 má pro naše "nevelké" potřeby velmi dobře zpracovaný datový model okolo zákazníků/dodavatelů, dodací a fakturační adresy, kontaktní osoby apod. Při nákupech u různých dodavatelů doma i v zahraničí (plus následná expedice, fakturace apod.) mám možnost pozorovat datový model na pozadí jejich roztodivných e-shopů, různé rovnáky na ohejbáky jak se data z e-shopu předávají do skladu/expedice/fakturace na pozadí - a málokdy se mi stane, že si řeknu "tohle mají stejně povedené jako i6" nebo případně "tohle by od nich i6 mohla obšlehnout". Naopak když potkám i6 e-shop u nového dodavatele, tak si obvykle docela oddechnu.

A protože e-shop je integrovaný, tak "karta produktu" obsahuje vedle interně-skladnických věcí rovnou i atributy, které vyplavou na webu - jak viditelný content (vlastně edit-box pro textový/HTML popis), tak různé volby jak se má produktová karta chovat přihlášenému/nepřihlášenému uživateli apod. Na e-shop je taky dotažena editace kompletního zákazníkova profilu, kontaktních osob a dodacích adres (což lze naschvál omezit), reklamace, expedice... Co tak potkávám v internetech, málokterý "jiný" e-shop má takhle podrobné rozhraní a hezky "všechno v jednom". A co se zadá skrz e-shop, je okamžitě v interní DB, nečeká se na nějaké dávkové zpracování z e-shopu do interního systému, transformaci dat z jednoho modelu do druhého apod. Prostě je ten e-shop bezešvou součástí toho softwarového balíku.

Entita "produkt" (v naší hantýrce taky "skladová karta") je prostá/jednopatrová. Takže třeba nejde mít nějakou sestavu detailně poskládanou z pár položek a s takovou sestavou o kus dál pracovat jako s "produktem vyšší úrovně" = používat ji nastojato v zakázkách (= i6: nabídkách a objednávkách), párovat ji na doklady přijaté od dodavatelů kteří toto umí apod. Což třeba SAP podle mého přirozeně umí, soudě podle toho, co padá z našich dodavatelů a zákazníků. Ona i6 taky cosi jako "sestavy" obsahuje, ale zatím co jsem viděl, vždycky z toho nakonec vypadne plochý seznam detailních položek. Nějaký modul "výroba" tuším taky existuje, ale my ho nemáme koupený.

Tlustý i6 klient (a vlastně i e-shop) je celý v "postarším" stylu "rozsáhlé formuláře nad tabulkami", přepínání seznam / detail. Nekonají se složité workflow procesy / wizardi (next, next, finish). Resp. to workflow je "implicitní", člověka to donutí k určitému postupu tím jak se odšedivují políčka a vyskakují chybové hlášky (často na úrovni integritních omezení v SQL), tzn. z toho statického formuláře to dopředu moc vidět není... Přesto základní práce = šoupání krabic je na zaučení dost jednoduchá - a to i pro kolegy, kteří entitně-relační diagram nikdy nepotkali.

1182

Vývoj / Re:Jakou vybrat technologii pro eshop?

« kdy: 07. 03. 2018, 08:03:05 »

Třeba i6 má v sobě už tolik užitečné business logiky a rozumných datových modelů, že ji těžko někdo dožene tvorbou "na zelené louce". A to říkám jako člověk, který jakožto "admin z nouze" skřípe zubama nad MSSQL a obecně nad závislostí na MS. Neznám přesně cybersoftí business model, ale vcelku bych se nedivil, kdyby dokázali instanci i6 pronajmout někde "na obláčku" - instanci databáze a aplikace pro další firmu to umí, připojit na to virtuální webík to umí, dovedu si představit že k tomu pronajmou i virtuálek pro tlustého klienta někde poblíž SQL serveru (nebo RDP/RDS desktop).

Hrozně záleží co všecko potřebujete pokrýt, jaký objem byznysu na tom má viset, kolik interních uživatelů na tom bude dělat apod. = jak moc se Vám vyplatí přehnaný komfort osvědčeného hotového řešení, ozkoušeného na milionu živých zvířátek před Vámi. Stačí Vám superlehký webový obličej a business procesy skrz firmu už si nějak nataháte (protože jste 2-3), nebo potřebujete aby to umělo taky evidovat zboží na skladě, podpořit nákup, finance, účtovat, víc jazyků(řečí), nepřeberné tiskové sestavy apod.?

1183

Windows a jiné systémy / Re:Synchronizace času doménových klientů

« kdy: 07. 03. 2018, 06:57:27 »

K předchozímu viz např. zde bod 5.

Díky za výživný odkaz - pro mě osobně výživný od A do Z.

Konkrétně k bodu 5:
takže "bývaly doby, kdy DC běžící ve VM (Hyper-V) uměl přebírat čas od hostitele a distribuce času v doméně takto fungovala. Ty doby jsou pryč. Odteď si chce DC ve VM správcovat čas striktně sám, brát ho z upstream NTP serveru." Přestože je to obecně z hlediska časomíry ve virtualizovaném prostředí možné méně vhodná varianta, dodávám já.

Líbí se mi, jak distribuce času ve Windows doméně funguje bezpracně, samospádem, včetně krypto-ošetření. Dokonce mám pocit, že W32time s každou novou generací Windows trochu dospěje. Bravo. Tzn. jenom na okraj chci zmínit, že to může fungovat taky mimo doménu, dokonce jako časová serviska na NTP klientech (včetně DC!) nemusí být použita W32time, ale open-source ntpd (Windows build).

Každopádně pokud NTP klient běží ve VM, ať už je na bázi W32time nebo ntpd, týkají se ho obecné nectnosti virtualizovaného prostředí pokud se týče časomíry. K tématu existuje obecný whitepaper od Meinbergů - autor Martin Burnicki je jejich dlouholetý klíčový vývojář ovladačů pro Windows a Linux. Jeho univerzální driver pod Windows, co se chytí cca od NT po Win10 na všechen jejich hardware (ISA/PCI/USB) je takový nepravděpodobný drahokam. Ten člověk ví o čem mluví. A mluví o spojitosti běhu softwarové časové základny v guest OS, která záleží na "spojitosti virtualizace" (ideálně vyhrazené CPU jádro pro guesta) a zejména na přesnosti/spojitosti/spolehlivosti doručování interruptů HW časovače - což není zrovna triviální požadavek vzhledem k tomu, že guest nevlastní fyzický čipset, ve kterém se tyto časovače vyskytují (vlastní nanejvýš CPU TSC a LAPIC timer, což je myslím trochu málo, on totiž není časovač jako časovač.)

Tradiční moudro bývalo, že ve virtuálu stojí časomíra za vyliž. (Což se na nenáročném klientovi ještě zkousne, ale na NTP serveru ztuha.) Nějakou dobu už ale slýchám dovětek, že moderní verze hypervizorů v tomto směru učinily značný pokrok. Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu, včetně závěsu na vnější NTP, PTP, PPS, co já vím (záleží co HV software podporuje). Druhá možnost je, nechat guesta, ať si spravuje čas sám, pokud se HV vynasnaží, neházet mu v tom klacky pod nohy - viz doručování timer interruptů.

Zcela souhlasím s tím, co už tady napsali jiní: bacha ať časovou základnu guesta nedolaďují na střídačku dva různé mechanismy. Pak se totiž "perou", přestane existovat jediná a jasná zpětnovazební dolaďovací smyčka.

Pokud se týče doladění skokem vs. spojitě, ta volba je samozřejmě kompromis, uvědomte si že při skokovém doladění může čas poskočit *dozadu*, což je v mnoha případech průser. V jiných případech je kriticky žádoucí, aby přesný čas seděl hned po doladění. Záleží na aplikaci = způsobu použití, oblasti nasazení. Je třeba si uvědomit, že pro volnoběh (softwarové) časové základny lokálního OS mezi dvěma "olíznutími upstreamu" je třeba dolaďovat frekvenci tohoto volnoběhu, a že nějaká reziduální nepřesnost bude nastávat pravidelně, ať už dolaďujeme výhradně spojitě nebo výhradně skokem.

Úplně přesnému času se lze přiblížit několika způsoby:

• dodatečným hardwarem a třeba ještě specializovaným API, které z toho hardwaru bude tahat časové značky
• slušně přesnou synchronizaci lokálního systémového času OS dokáže poskytnout PPS vstup, ale ten pod Windows pokud vím nelze na generickém PC HW zavést (pod Linuxem ano, skrz sériový či paralelní port, nebo skrz síťovku s HW podporou PTP)
• což mi připomíná, že z hlavy nevím, jak často dolaďuje frekvenci SW časomíry OS Meinbergovic serviska běžící v přítomnosti Meinbergovic přesných HW hodin (PCI-e) - možná každou sekundu? Každopádně se to té systémové PPSce bude dost blížit
• v národních laboratořích etalonu času se vyskytují extrémisti, kteří si fázově zavěsí centrální oscilátor PC motherboardu na vnější frekvenční normál, takže pak servosmyčka časomíry v OS rychle zkonverguje ke konkrétní hodnotě, která se dál už prakticky nemění (protože ten mizerný šutr na motherboardu už nevandruje)

Závěrem obligátní poznámka: softwarová systémová časomíra pod Windows má přesnost poměrně omezenou reálnou granularitou časových značek. Za starých časů to bývalo 15.6 ms (perioda scheduleru), tuším od Win7 je to 1 ms, netuším zda v nejnovějších 10/2016 se to třeba dál nezlepšilo. V Linuxu už drahně let není problém, aby ntpd vykazoval reziduální offset v nízkých jednotkách mikrosekund pokud má PPS, nebo cca 20-50 us pokud bere čas po nezatížené LANce od kvalitního stratum 1.

1184

Studium a uplatnění / Re:Jak nestagnovat jako linuxový admin

« kdy: 07. 03. 2018, 05:22:41 »

Tyjo, to jsou konce... když tohle čtu, tak jsem nakonec rád, že jsem admin tak na 5% úvazku a proto v roli admina konzervativní lopata.

Instinktivní potřeba pracovat s pořád většími a dražšími a exotičtějšími krabicemi (nebo rozsáhlejšími sítěmi apod.) se mě nějak nedrží. Malý hardware, malé problémy.

Když jsem se dřív živil primitivní adminskou prací, vyvstávalo přede mnou spousta nápadů na programátorskou práci, jejíž plody by mi ušetřily rutinu - akorát v té době jsem pro samou rutinní činnost neměl čas něco programovat. Motivace programovat - to už se dneska nevyskytuje? Možná mám jenom kliku, kam jsem se jako zaměstnanec přitočil. Že je to pestré (někdy až moc), a že mě nechají dělat, čeho se chytnu.

1185

Sítě / Re:Jsem připojená k síti (wifi), ale intertnet nejde

« kdy: 06. 03. 2018, 17:52:37 »

@MD: velice Vám děkuji za působivou smeč :-) Takhle v kostce bych se tohle všechno nikde jinde nedočetl.