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

Stran: [1] 2 3 ... 7
1
Sítě / Re:Konfigurace IPv6 na Linuxu
« kdy: Dnes v 13:19:43 »
Je pravda že to v té wiki není popsané,"kde se vynoří" přidělování adres. Ale pochopil jsem to z toho že nijak, prostě máte tunel a jak si zařídite adresaci je na vás. Třreba staticky nebo přes systemd-networkd monstrum. Doporučuji kouknout na man systemd.network a direktivy IPv6AcceptRA=, IPv6SendRA=,, IPv6Prefix=,, IPv6RoutePrefix=, LinkLocalAddressing=,DHCPPrefixDelegation=/[] (atribut nebo sekce)


K ukázce kódu od jjrsk z KB mám dotaz: (je to i řádek z té KB):  To "preventivní" přidání /48 unreachable funguje jenom za mým konecem tunelu  směrem  k zařízením a nebo "i probublá" i blíž ke zdroji  a tím  "odlehčí" větší části trasy (přes nějaké ICMP6 zpráve /route annoucement pro ipv6 které pro mě jsou nové), že i někde "výš" do bude vědět, že toto destination neexistuje? A nebo tento řádek routy čistě se projeví jen od mého konce tunelu k zařízením?
JJRSK se asi ptal  na tento zápis pro mikrotik, mě to zajímá obecně, na jakých místech tohle operuje a odkud "dropuje" a případně nějak propaguje neexistenci i dál. To vím, že, specifičtější routa /64 na reálné rozhraní s reálnou podsítí ji překryje.Píše se tam , aby se paket nevracel tunelem zpět... Ale nevím jestli je to správně řečené ataky jestli právě ze prvky v cestě výš dozví/nakešuju informaci o neexistenci cesty. Protože mám tušení, že u IPV6 něco takovéhleho jsem někde na VPS viděl.
Edit:
/ipv6/route/add dst-address=2a03:3b40:XXX::/48 blackhole
Jestli tohle jeste porad plati (vhledem k tagnuty v7 predpokaldam) tak to jednoznacne indikuje, ze soudruzi z mikrotika jeste porad ipv6 vlastne vubec neumej.
...UnassignedubnetPolicy=  v .network s tím souvisí (chápu z toho že při hodnotě blackhole  to "za vás" řádek vlastě přidá ) v případě linuxu, ne mikrotiku

2
Nemá Delete cache + Delete data zbytečně devastující účinky  že smaže i preference nebo jiné data?

Nemám sice zkušenost s gmail aplikací a imap serverem(Ale smtp, ale přes TLS by to mělo být stejný flow)
Možná by pomohlo jenom v nastavení mailového accountu změnit hostname /IP adresu daného serveru. Ono to totiž po uložení může očuchat SMTP server, a tím "natáhnout" data o expiraci nebo změně certifikátu a bude klid.

Doporučuju udělat změnu typu "úkrok stranou a zpět": z původníh osprávného IMAP nastavíte jiný IMAP, který nebude fungovat uložíte, killnete, spustíte, nastavíte původní IMAP.

3
CNAME cloaking hadr. Tohle DNS firewall s detekcí CNAME neodhalí,protože zločin se odehrává na totožné doméně.
jde o url /tajnyslovo/gs/ccm/collect?rcb= (xhr) případně rovnou /tajnyslovo/R3_Z_ZPxyzdhkslhash
V desktopovém prohlížeči mohu nasadit ublock origin  pro blokaci url ^collect.+, případně abort-current-inline-script:has(google_tags_first_party) nebo tak) a i tak nemám 100% jistotu. Dá se třeba podle hlaviček


Příklady:
bike-eshop.cz
cyklobazar.cz
www.hudy.cz
(filtrace požadavků : "rcb", "ccm", "gtm")


Je reálné to zablokovat pro nic netušící oběti za routerem? Každá stránka (i bohužel české) mají tajnyslovo jiny

Máte nějaký typ jak na jedním tahem zablokovat na všech doménách šmírování google které je maskované přes  subURL navštívené domény? Představuju si to, že pachatelé webmasteři mají něco jako v nginxu location /tajnyslovo/ {proxy_pass googleblabla.com/;}


Důkaz: url /tajnyslovo (bez konečného lomítka! na konci)
Citace
404. That’s an error.
The requested URL /g00a was not found on this server. That’s all we know.
Sice mohu nasadit těžké zbraně do prohlížeče

Inicializováno to je pravděpodobně v kořenovém html.
Kód: [Vybrat]
(function(w,i,g){w[g]=w[g]||[];if(typeof w[g].push=='function')w[g].push(i)})
(window,'GTM-R3_Z_ZP','google_tags_first_party');</script><script>(function(w,d,s,l){w[l]=w[l]||[];(function(){w[l].push(arguments);})('set', 'developer_id.dYzg1YT', true);
w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s);j.async=true;j.src='/tajnyslovo/';
f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer')


Dá se proti tomu nasadit něco  účinného kalibru na jednom  centrálním místě sítě (routeru) ? Protože jsou i chudáci s prohlížečem safari nebo chromím mobilním chromem, kde rozšíření si nedají natož nezjistí, co jim podtéká pod proxy.

4
Odkladiště / Re:Ktore hoby projekty ste dokonćili vdaka AI?
« kdy: 12. 09. 2026, 22:00:43 »
OdpověĎ přečíst až prvního báse šedesátýho čvrtý..: YmFrYWzDocWZa3UK

5
Server / Re:Zjištění stavu síťového adaptéru v QEMU
« kdy: 12. 09. 2026, 21:58:48 »

Příspěvek jsem měl rozepsaný  den 2 předem, až teď jsem si všiml že zustal nerozepsaný.
František Ryšánek.:
To možná právě popisujete právě  tu druhou nefunkční metodu  od té AI  sys/class/net/tap166/operstate (Já to zabalil do *166*) a už jsem si prošel procesem pochopení přítomnosti balíků rozhraní fwpr,fwln spojených lepidlem fwbr (rozhraní s "i0" jsou v tom individuálním bridgi a "p0" jsou v vmbr0). Podle mě to má jiný důvod :managovatelnost pravidel firewallu pro každý VM 
 nebo vůbec nemožnost aplikovat firewall pravidla na TAP,a pak spekuluju možnost přiřadit MAC adresu/měnit. (Jelikož MAC guesta není nikde vidět v host:ip link) A hlavně fungovat s Vlany (non-aware, aware), případně SDN a zónami,fabrics(tam jsem se ještě nedostal) Nebo že nelze provést brctl addif bridge1 bridge =  mít jedno interface ve víc bridge. 

Pro vznik 2D struktury se jako lepidlo druhé osy používaj páry veth (první osa bridging))))

PS: docela mě štve, až autocompletion háže fwpr166p0@fwln166i0, ale má to za @ tam nepatří už, takový neumazaný příkazy vyplivnou Device ...@... does not exist. . Aspoň že je vidět hned hned  peer toho rozhraní za zavináčem.
Pár tvoří fwln a a fwpr.  Vlastně veth řeší problém jak zapojit "něco" do dvou bridge.



Nerad bych byl aby instalace geust agenta byla jediné řešení. Já v to doufám, protože nastavit link state jde zvnějšku a bez použití guest tools agenta, tak proč by to nešlo i přečíst.
To jsem psal, že si myslím, že disable rozhraní v OS a link state roho rozhraní jsou 2 nezávislé věci


panpanika, skoro mám pocit, že zakopaný pes je v nové verz 9.2 vs 9.1...

6
Windows a jiné systémy / Re:Nějak se bugly okna v Chrome
« kdy: 10. 09. 2026, 16:31:16 »
Protože jde o historické dědictví. Vždyť před 6 lety byl podporovaný, tak jako teď je jiná doba, jiné znamení zvěrokruhu/ odvrácená strana microsoftu / trend ??? Na internet se s tím nebojím, v "VM jailu" je co má být jen.

7
Odkladiště / Re:Banka přátelská k open-source softwaru
« kdy: 10. 09. 2026, 16:28:45 »
Moneta. Po loginu neodklikávat souhlas s SMS, ale pokračovat dál (Ctrl F12 , Ctrl Shift I  ).

Z českých bank bych uvažoval dál o fio a mbank, protože ty banky jsou prostě "jiné" než mainstream.

8
Odkladiště / Re:Banka přátelská k open-source softwaru
« kdy: 10. 09. 2026, 12:11:54 »
Od banky, kde není (nebo přestane být )přístupová metoda to budu "resit" takzvaně posledním výběrem peněz.
Pro mě je kritérium antivendor lockin a přenositelnost. Proti tomu aplikace v tamagoči s proprietárním OS dvou vyvolených výrobců, která se jinak oficiálně stáhnout nedáa  která každý 2 měsíce potřebuje aktualizaci nebo závisí na nerozbití čtečky otisků prstů je úplný jiný svět(a je nutné to řešit na pobočce, které mizí z mapy jako  pravice v politice). Ale chápu že to je pohodlnější.
Některé banky asi moc dobře ví, že ty starý dobrý SMS (vlastně už ne dobrý ale otravný od doby co prodloužili počet číslic kódu ze 4 na  8 k opisování) pořád neoficiálně nechaj pokoutně fungovat,akorát za cenu  neustálých varování a workaroundů , člévěk si musí dávat majzla aby si tuto cestu neodřízl ( a nebo  paradoxně nepovolil, ale za přihlašné od té doby napořád)

9
Windows a jiné systémy / Re:Nějak se bugly okna v Chrome
« kdy: 10. 09. 2026, 12:06:00 »
Ještě že  mám snapshot "-1" , kde to bylo polorozbité (s zmizelým oknem ale před totální crashem) a snapshot "-2", kde to rozbité nebylo , ale ten zase není tak aktuální.

Je to Windows 7 a chrome je verze stovka,takže se vejdu tabulek  :D . Co je na aktuální verzi v dané době pro daný OS v té době špatného? V té době to byla aktuální a poslední verze . Nejsem FOMO updater.
 
Kategoricky odmítám že došla paměť. Zaplnění RAM je do 40% OK, skoro stejné jako "Potvrzeno".(Jak se to přeloží). Jenže jak browsuju dál a dál, zatížení RAM vzroste na na 60% a pak už potvrzeno se blíží k 95%. V tu chvíli musím musí použít  rovnák=swap   na ohejbák  "Potvrzeno" (protože programy ve windows spadnou podle toho se zaplní dřív) a když vím, že Potvrzeno se blíží k 80%, tak zapnu SWAP, obvykle na 1/2 množství RAM.. Případně dosypat až na 1:1 mznožství RAM, to pak vychází, že RAM se zaplňuje zhruba stejně jako to proklaté "Potvrzeno".
To že došla paměť se mohlo stát ale spíš nějak že by mi fakt něco uniklo, protože  mám spuštěnou utilitu která mi ukazuje zatížení paměti (protože Správce úloh tenhle údaj potvzeno Tají),
Vůbec, to by mě zajímalo, proč to zatížení  veličin "Potvrzeno" a "fyzická paměť "má takovouhle tendenci, že Potvrzeno  "se zaplňuje rychleji" a musí se dofukovat swapem.

Nemám pocit, že by to byla polonefunkční konfigurace.... Stává se to tak jednou v 1 ze 100 běhů browseru. A ani virtualizace s tím nemá co dočinění, stávalo se mi to i při běhu totožného disku na reálném HW.
Mám pocit že je to nějaký bug window managementu samotného chrome/modálních oken/dialogů pro upload. Má to dvě fáze. okno zmizí,, ale jede se dál. 2: při několikátem drag+drop tabu vše spadne. Zároveň mi nastal i scénář, kdy když to bylo takhle zmizelé bylo možné najít vhodný (a vhodnýhotypu)proces chromu ,který byl suspended(crashdump zombie windows analogie) a killnutím/resume se to "nějak" poštelovalo . Ale je to taková ruská ruleta, jindy to instantě crashne všechny procesy chromu.

10
Poznatek: když v tom neviditelném okně dám Ctrl+D, tak toto modální subokno je vidět a je ovladatelné.

potud Fajn. Jelikož jsem psal, že okno jde normálně resizovat a při ježdění po horní hraně okna  se mi ukazují minipopupy s tooltipy názvú oken a kousek podtím i kurzor mění typ na textový prompt,
odhodlal jsem se myší přesunout jednotlivé taby neviditelného okna do nového okna jeden po druhém.

Podařilo se mi takhle z potápějícího titaniku přesunout 2 tabažéry do nového okna . Při třetím tabu  kurzor po chvíli se změnila na "BUSY" kurzor a jiný okna  chromu z šedly a po 10sekundách celý chrome spadnull. Mělo mi být divné že nově přesunutá plocha tabů je šedá (ale komplet šedá, bez chybové hlášky KILLED apod. uprostřed) a je nutný reload.


11
Server / Re:Zjištění stavu síťového adaptéru v QEMU
« kdy: 09. 09. 2026, 19:42:13 »
Vzbuzujete ve mě paniku pane. Já celou dobu řeším VM.
Já v těch výpisech vidím jediný  rozdíl který z nich značí vytažený virtio kabel a který zapojený:
Zkusím věštit a znamená chybějcí JSON property statistics, že kabel je vypojen?

Jenže řešení nefunguje bez guest agenta!
Od začátku threadu středobod dotazu byl, jestli existuje nějaký protipól příkazu  set_link net0 hodnota , který (taky!!)nepotřebuje agenta a mohl by se jmenovat třeba get_link net0 nebo info_link_štátus net0


Síťové rozhraní může mít ip adresu i když je kabel nepřipojen (VM může být i Windows, Haiku, novomenteOS)



Příkaz monitor:

Příkaz  by měl udělat přesně to samé jako když provedu sekvenci
- spustím příkaz "qm monitor 166" # parametr je  VMID
- v něm konečně milostivě spustím příkaz "196" # to byl překlep / zavádějící, příkaz 196 neexistuje. Ale libovolný příkaz z výstupu příkazu "help", třeba "mouse_button 4"  ENter, za ním "info name" Enter
-Následované Ctrl+D - protože jak jinak se dostat z toho vězení  "qm>"

Takže
Kód: [Vybrat]
echo  echo -rn "mouse_button 4\ninfo uuid\n\0" |base64 > pepa.txt by měl programeticky  = na dálku = ne-interaktivně kliknout myší ve VM 166, a vrátit uuid mašiny a výsledek base-64 zakodovaný uložit do pepa.txt

Jenže je tam ta překážka že ve skutečnosti to takhle nefunguje, ten příkaz qm monitor nechce fungovat  tímhle způsobem, že mu do STDIN nasypu příkazy a jeho výstup si vyzvednu v STDOUT.

12
Odkladiště / Re:Banka přátelská k open-source softwaru
« kdy: 09. 09. 2026, 17:52:52 »

1 Ano os je self build GOS s nejakymi vulapsenimi a vlastnim podpisem.

2 ze i kdyz to technicky treba zrovna funguje, tak je porusujes (uplne minimalne podminka stazeni z oficialniho zdroje).
2: jakym způsobem vůbec se stahují "appky z google play" na diskriminovaných androidích OS? Naposledy jsem šaskoval s aurora store, ale po roce to asi přestalo fungovat. a bylo to takové podivné řešení nabízející podivné režimy fungování jako založení/identifikace nějakým vymyšleným (náhodným) google accountem , nebo nějakým jejich vytvořeným

 Tím pádem , nakonec to stahuje apk z oficiálního zdroje ne?

Ještě že appky z google play nepotřebuji

13
Server / Re:Zjištění stavu síťového adaptéru v QEMU
« kdy: 09. 09. 2026, 17:42:24 »
To se podivuji, že až teď píšeš, že pracuješ s CT=LXC ... To pak je jiná vesnice (jak už mi bylo divnéz toho že to vidíš v GUI) přitom příkaz pct tu doteď nezazněl (za to qm vždy = mimikry) a není se divit, že si nerozumíme.


K tomu dodatku, věštíš špatně. Zrovna ses trefil do příkazu sendkey, který shodou okolností existuje ve variantě proxmox příkazu "qm sendkey" a zároveň   uvnitř Monitoru(záložka Monitor vybraného VM) přímo příkaz "sendkey". Já ale chci na dálku nebo skriptem spustit nějaký příkaz přímo do toho Monitoru.

Jako příklad info network.
Představoval bych si:
echo 196 | qm monitor 196 | grep -P ifname.+?,
Jenže se spustí qm monitor 196 bez žádného vstupu a čeká na příkazy



A zároveň poslat výstup daného commandu do pípy... To se ale blbě dělá, když znásilní /přivlastní si shell

14
Server / Re:Zjištění stavu síťového adaptéru v QEMU
« kdy: 09. 09. 2026, 15:41:41 »
Kde ty v GUI vidíš / můžeš menit stav link_down? Píšeš o tom na konci postu. Já mohu měnit link state jen pro LXC("Disconnected" checkbox)  .

Jakám způsobem disconnectuješ rozhraní, když na řádku net0 máš dokonce link_down v obou případech? Já v žádném. dokonce jsem zkoušel qm config  166 --current.

Mám 9.1.6, virtio síťovku a guest tools nemám:Summary:Guest Agent not running. Napadá mě že to by mohl být důvod, že někde v GUI je tlačítko pro link state, které je mi ukryté,
Hlavně mě je divné, proč  by pro čtení link state (kéž by existoval příkaz get_link) byl nutný guest agent (jak možná naznačuješ), když pro zápis(set_link) není nutný. Navíc jde o operaci "zvnějšku"  guesta . Je to nezávislé na stavu ve správci adaptérů   Zakázat/Povolit

PS: set_link net0; je neplatný příkaz

PS: jde ti spustit nějakým způsobem z shellu proxmoxu příkaz XYZ pro qm monitor takzvaně jedním tahem? Něco jako oneliner.  Třeba kdybych ho chtěl spustit ze skriptu. Mě se to nedaří. ten příkaz qm monitor se nedá přesvědčit, aby nějak akceptoval příkaz do stdin a nějak trvá na tom, že tam musí být zadán interaktivně. Tím myslím jako napsat příkaz XYZ do web gui  - VM - Monitor do jednořádkového toho inputu a jeho provedení. Ale přes shell automatizovaně..
Něco jako
 echo xyz | qm monitor 123
 echo xyz > /dev/char/10:116 / /run/qemu-server/116.*  (něco jiného z find / -maxdepth 4 -iname "*196*" |grep -v disk)

15
Já nezabíju záměrně. 
ve windows  :Zabije to zkratka ~Ctrl+Z,
v linuxu: shodí na pozadí.

Mě šlo primárně o ten quirk windows, proč se chová jinak než je zvykem. Desktruktivně.

Stran: [1] 2 3 ... 7