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 - rats

Stran: [1]
1
Sami efektivní plánování logistických tras nespočítáte - nechci vás podceňovat, ale i velcí hráči na logistickém trhu si kupují hotová řešení.
Pokud jste zmiňoval Plantour, tak ten konkrétně doporučit mohu - vím, že ho používají nejméně tři velcí hráči na českém trhu. ALE určitě i tak budete muset mít alespoň základní představu, na jaký parametr plánování tras přesně cílí - zda na rychlost (čas), na nákladovost, na co nejmenší počet vozidel v terénu, na dodržování pracovní doby apod. Ideální řešení neexistuje, a to ani v době AI a poměrně komplexních datových modelů. Může se také stát, že naplánovaný "matrix" bude tak složitý a provázaný, že si s ním neporadí vaši dispečeři nebo řidiči. Někdy zkrátka méně znamená více.

2
Tak v první řadě pro iDRAC je prakticky vždy dedikovaný síťový interface, který jinak nelze nijak využít. Nijak. V OS ho neuvidíte a nijak ho tam nedostanete. To, myslím si, dostatečně zajišťuje oddělení vrstvy OS od vrstvy iDRAC.
Jediný způsob, jak zařídit komunikaci mezi iDRAC a OS, je Dell ISM (Idrac Service Module). Komunikace se řeší přes virtuální dvojici síťových interface na Link-Local adresách, a je pro ni třeba mít aktivní příslušné nastavení v iDRAC, a v OS nainstalovanou službu ISM, která si nahodí virtuální rozhraní pro komunikaci.

Ale i v případě instalace/existence ISM nemáte žádný přístup k management interface iDRAC. Dell designoval iDRAC jako zcela izolovaný nástroj pro low-level management serveru (dnes tam můžete dělat úplně totéž co v BIOSu, ve správě řadiče RAID, ve správě síťovek apod.), a ve výchozím stavu nelze nijak z OS k iDRAC přistoupit.
Samozřejmě může existovat vektor útoku na samotný iDRAC, na jeho FW, ale nemyslím si, že by takový existoval přímo z OS.

Vzhledem k tomu, že iDRAC umožňuje nastavit pevně daný set IP adres, ze kterých můžete na management interface přistupovat, tak je možno velmi přesně nastavit pravidla pro přístup zvenčí.
Dále se předpokládá, že management síť s iDRAC je izolovaná od všeho ostatního, a vstup do ní se realizuje přes firewall, a přes nějaký AAA mechanismus (např.: RADIUS).
Veškerý odchozí provoz, zdrojovaný z IP iDRACu, je zakázán, povolen jsou pouze směry SMTP server (notifikace) a interní mirror updatů pro daný typ/model serveru. NTP, DNS a další podobné služby jsou pro management interface zbytné, a jsou tedy jednak zakázány, a druhak blokovány.
Dále autentizace k iDRAC umožňuje používat adresářové nebo LDAP služby, takže můžete mít přístup do iDRAC svázaný s vaším AD/LDAP atd.

Za velké zlo považujeme nástroj OpenManage Server Administrator pro Windows, který se instaluje do OS, a má (po autentizaci a autorizaci uživatele) přímý přístup ke konfiguraci serveru (byť omezený oproti iDRAC). To už "smrdí", pryč s tím, nedává to zvlášť v případě Enterprise licence k iDRAC vůbec žádný smysl. Ale u některých "pre-install" Windows na Dell serverech je bohužel tato věc už rovnou nainstalovaná.

Pokud mám hovořit sám za svoji praxi, tak iDRAC zrovna není to, co bychom považovali za potenciální vektor útoku. Je třeba si uvědomit,, že iDRAC slouží v naprosté většině ke konfiguraci serveru na začátku jeho životního cyklu, poté k pravidelným updatům firmware, a pro disaster recovery účely v případě, že selže OS serveru a není jisté, co se děje. Každopádně to není určitě věc, ke které by se měl někdo připojovat obden, nebo pravidelně, a pokud se obejdete bez notifikací z iDRAC, je možné v ultra paranoidním řešení i mít trvale shozený port, do kterého je iDRAC připojený, protože na chod serveru to nemá žádný vliv. Takový přístup jsem zažil v praxy, a upřímně řečeno, to už mi přijde poněkud přehnané, hodně z kategorie "security by obscurity".

Za mě se určitě iDRACu nebojte, jeho výhody, přednosti a možnosti značně převyšují možná rizika.

3
Tak presne tohle vam dnes operator zaruci, ...

leda na papire. Fixni lte (jakoze 5G) behalo mezi nekolika BTSkami, podpora nevedela proc a ocividne s tim neminili nic delat. Kvalita spojeni behala nahoru a dolu, podle toho jak si to hodilo kostkou. Po par tydnech drop v dosazitelne rychlosti pod polovinu rychlosti po instalaci, vsak je to ok protoze rychlost je "az x mbps". Osobni zkusenost. Jako backup linka proc ne...

Fixni LTE neni zadne "5G" - je to na soucasne 4G siti. Sice je pravda, ze site 4. generace s fixnimi pripojkami nepocitaly, s temi je opravdu pocitano az u 5G siti, nicmene to neznamena, ze to na 4G nelze.
A nemuze behat mezi BTS, protoze ma vyhrazeny timeslot na jedne konkretni BTS. I proto, pokud byste LTE router s "fixni" pripojkou prenesl k jine BTS, tak se vam sice neodpoji, ale klesne vam rychlost na stejne minimum, jako kdyz napr.: vycerpate FUP.
Ale urcite zapomente na jakykoliv problematicky paket loss/drop - kolisaji latence a jitter, nicmene s tim se pocita. Ale neni to nic dramatickeho. Statisticky muzu rict, ze packet loss na tech LTE linkach je zhruba 0,01 procenta, a vykyvy rychlosti zhruba -15 procent.
Jako zalozni linka je to za idealnich okolnosti nerozpoznatelne od 32 Mbit MW nebo FWA spoje. S optikou je samozrejme nesrovnatelne nic, ale zase na druhou stranu kabely nikdy neslo (a jeste dlouho nepujde) s jakymkoliv bezdratem srovnavat.

4
Citace
Tak tohle bych rad videl v realite, operator nezaruci vubec nic, ani kvalitu signalu ani konkretni BTS. Vykousel jsem dva poskytovatele, ale nastesti to nedavno vyresil kabel. Kvalita tehle "5G, 5G ready" reseni je k placi, mozna ale jenom spatna lokalita.

Tak presne tohle vam dnes operator zaruci, a to nejen v SOHO sfere, ale i enterprise. Instalace je svazana s konkretni BTS (proto je to “fixed” sluzba), a je vyzadovana outdoor antena - operator vam to nepovoli ani na Cisco 800 series routeru s indoor antenami.
Rychlost si muzete dojednat, tusim, ze v nekterych lokalitach je mozny uz i 100 Mbit.
Pouzivame LTE o rychlosti 32 Mbit jako zalohy k FWA, MW a fiber primarum, a mam s tim nejlepsi zkusenosti.
V lokalite, kde fixed LTE chcete, ale musi byt samozrejme splneny dve podminky - volne “misto” na BTS, a spravny typ BTS. Verim tedy, ze nekde v horach nebo v odlehlem miste muzete narazit na problemy - ovsem paradoxne s tim operator daleko vic valci v aglomeracich nez na venkove - duvod vam je asi jasny.

5
Sítě / Re:Vyžaduje konfigurace CISCO AP kontroler?
« kdy: 26. 02. 2020, 11:45:34 »
Zapomente na Mobility Express, to urcite neni to co potrebujete.
Lightweight IOS je urcite presne to, co nepotrebujete - to je totiz AP zavisly na controlleru.
Autonomous IOS je presne to, co potrebujete - kazde AP pak bude fungovat samostatne a bude samostatne konfigurovatelne.

Vy mate bohuzel same LAP (Ligtweight), takze budto potrebujete controller, anebo do nich zkusit dostat autonomous IOS. Do nekterych typu to slo - hledejte na Google.
Proc Mobility Express nepotrebuje? Pokud by to AP podporovala, tak je to pro 90% SMB nasazeni idealni a asi 500x lepsi nez Autonomous.
V cem je Autonomous lepsi nez LAP? Jako, ze si muze nastavit 30 AP kus po kusu a navic pres jedno z nejdebilnejsich webovych rozhrani, ktere kdy existovalo? A kanaly si bude nastavovat rucne? A co roaming?

Jak jsem jiz psal - oba firmware (LAP, autonomous) jsou pro vsechny 3 modely AP dostupne. Na dohledavani a stahovani firmware neni google ale Cisco support portal (a kontrakt). Nahravat tam firmware stazeny nekde z internetu neni ani bezpecne ani legalni.

Pane kolego, nezlobte se na me, ale vy vubec netusite, o cem pisete.
Cisco Mobility Express je reseni, ktere se da strucne popsat jako AP s virtualnim WiFi kontrolerem v sobe. A stejne strucne - ma to spoustu nevyhod, a Cisco to podporuje jen na relativne malem portfolio AP se specialni verzi IOS. Doporucuji si to vyzkouset v praxi na vice nez dejme tomu 2 AP, a pak muzeme porovnat zkusenosti.

Lightweight (controller-based) IOS je vam uplne k nicemu. Takove AP spoleha po vsech strankach na controller. K tomu neni co dodat.

Autonomous IOS by nejspis bylo jedine prijatelne reseni, ale bez servisniho kontraktu je tezke ho ziskat. Ne vsak nemozne - image se da vytahnout z typove stejneho AP, ktere je Autonomous. Bezne jsme takhle preklapeli 2602 z Lightweight do Autonomous a zpet.

Konfigurace Cisco Autonomous IOS pres webove rozhrani? Jako vazne? To nikdo (snad krom ruznych experimentatoru) nedela, od toho je u Cisco konzole.

Pokud ale mate "starost" o bezpecnost a aktualnost, tak v tom pripade byste mel poradit pouze jedine - hodit ty AP do elektroodpadu, protoze to jsou vsechno obstarozni typy, ktere jsou pro Cisco end-of-life.

6
Sítě / Re:Vyžaduje konfigurace CISCO AP kontroler?
« kdy: 25. 02. 2020, 22:20:30 »
Zapomente na Mobility Express, to urcite neni to co potrebujete.
Lightweight IOS je urcite presne to, co nepotrebujete - to je totiz AP zavisly na controlleru.
Autonomous IOS je presne to, co potrebujete - kazde AP pak bude fungovat samostatne a bude samostatne konfigurovatelne.

Vy mate bohuzel same LAP (Ligtweight), takze budto potrebujete controller, anebo do nich zkusit dostat autonomous IOS. Do nekterych typu to slo - hledejte na Google.

Stran: [1]