Byla vydána nová verze 15.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Vývojáři Ubuntu představili projekt Myna, tj. iniciativu zaměřenou na přidání funkce převodu řeči na text do prostředí desktopu Ubuntu. Dle plánu již v Ubuntu 26.10.
Společnost Epic Games představila nový open source systém pro správu verzí Lore navržený pro "bezprecedentní škálovatelnost dat i týmů a optimalizovaný pro projekty, včetně her a zábavy, které kombinují kód s velkými binárními soubory, aby uspokojil potřeby vývojářů i umělců". Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Úřad pro ochranu hospodářské soutěže (ÚOHS) provedl v říjnu 2024 místní šetření u společnosti Seznam.cz. Úřad prověřoval důvodné podezření na možné protisoutěžní jednání, konkrétně zneužití dominantního postavení. Krajský soud v Brně v květnu 2025 konstatoval, že toto šetření bylo nezákonné. Nejvyšší správní soud (NSS) včera rozhodl, že šetření bylo provedeno v souladu se zákonem. Krajský soud bude muset případ posoudit znovu.
Byl představen skládací telefon Commodore Callback 8020. Ani hloupý, ani chytrý. Pro fanoušky Commodore a digitálního minimalismu. Bez webového prohlížeče a sociálních sítí. S předinstalovaným WhatsAppem. S operačním systémem Sailfish OS.
V OpenBSD byla objevena 27 let stará chyba v ppp pomocí níž lze vzdáleně obejít autentifikaci. Chyba byla nahlášena 12.6. a 14.6. byla opravena. Bližší info v článku A 27-Year-Old Authentication Bypass in OpenBSD's PPP Stack.
Odpověď Evropské komise (pdf) k evropské občanské iniciativě Stop Destroying Videogames, jež je součástí hnutí Stop Killing Games: "Komise se domnívá, že v této fázi nemůže navrhnout právní povinnost zachovat hratelnost videoher poté, co přestaly být poskytovány komerčně. Důvodem jsou i stávající práva duševního vlastnictví. Podle autorského práva EU mají nositelé práv výlučná práva ke svým výtvorům. Kromě autorských práv mohou být
… více »Byl vydán Mozilla Firefox 152.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 152 bude brzy k dispozici také na Flathubu a Snapcraftu.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.7 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
Hříčka xsnow, která na ploše spustí sněžení, je protestware. Pokud jste v Rusku (LANG=ru), zobrazuje ukrajinské vlajky.
Zdravím,
mám server Debian lenny, u kterého prapodivně zlobí ping na výchozí bránu a do internetu. Zajímavé je, že na všechny ostatní PC v síti a na něj se bezproblému dostanu, ale jakmile ze serveru pingnu bránu (192.168.0.1) , ping jakoby zamrzne, a dále už nic nevypisuje. Dle výpisu spojení na bráně, ICMP pakety minimálně příjdou, jestli odejde i odpověď nevím. Ping z brány na server je funkční. Když se chci na tento server připojit z internetu přes ssh opět to nefunguje a server je nedostupný.
Server se chová tak, jako by neměl vůbec nastavenou výchozí bránu (zaseklá??). Při jakémkoliv kontaktu s vnějškem je server nedostupný.
Na serveru běží DNS server,samba,ldap,nagios centreon,apache2,mysql. Aktuálně na serveru není aktivní žadný firewall.
2X se mi stalo, že se zničeho nic ping a celá komunikace rozeběhla a pak zase po pár minutách zanikla.
Rozhrani eth1 neni připojeno a nepoužívá se. Příkaz arping 192.168.0.1 funguje. Server začal zlobit po výpadku elektřiny. Dosud bylo všechno OK. Zkoušel jsem zastavit všechny služby vypsané nahoře, reset serveru, odstranění a znovu přidání výchozí brány, reset interfaces ale nic mi nepomohlo. V dmesg vypadá také vše OK.
Díky za rady, už jsem vybouchal všechny možnosti. Níže jěště základní nastavení:
ip a show
1: lo: < LOOPBACK,UP,LOWER_UP > mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: eth0: < BROADCAST,MULTICAST,UP,LOWER_UP > mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether AA:BB:CC:DD:EE:FF brd ff:ff:ff:ff:ff:ff inet 192.168.0.9/24 brd 192.168.0.255 scope global eth0 inet6 fe80::204:23ff:feb7:e6da/64 scope link valid_lft forever preferred_lft forever
3: eth1: < BROADCAST,MULTICAST > mtu 1500 qdisc noop state DOWN qlen 1000 link/ether AA:BB:CC:DD:EE:FE brd ff:ff:ff:ff:ff:ff
4: vboxnet0: < BROADCAST,MULTICAST > mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff ip route 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.9 default via 192.168.0.1 dev eth0
cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0 iface eth0 inet static
address 192.168.0.9 netmask 255.255.255.0
#post-up iptables-restore < /etc/iptables.up.rules
gateway 192.168.0.1
cat /etc/resolv.conf
nameserver 62.129.50.20
nameserver 8.8.8.8
Řešení dotazu:
iptables -t filter -L -n iptables -t nat -L -nA pokud to bude v poradku, tak zkusit tcpdump na obou stranach a podivat se, jestli na 0.1 paket prijme, jestli od ni odejde odpoved, atd..
iptables -t filter -L -n
iptables -t nat -L -n
Oba shodně: Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Aktuálně nemám žádná pravidla. Nic by se nemělo routovat, ani zahazovat. Bohužel brána není linux s konzolí, má to pouze webmanagment. A nemohu si dovolit dělat nějaké větší zásahy. To samé i se serverem. Z kontroloval jsem kabely vše ok. Jednou za čas se to samo cca na 5 minut rozběhne a pak zase zdechne.
Ještě chci vyzkoušet nabootovat jiné jádro, jestli se to aktuální (2.6.26-2) nepoškodilo.
A neměl jsi špatně sítě masky na obou stranách?
Všechny Pc a servery mají IP ze sítě 192.168.0.0 a masku 255.255.255.0. MAC brány je aa:aa:aa:aa:bf:38.
Arping na bránu z jiného serveru:
arping 192.168.0.1
ARPING 192.168.0.1 from 192.168.0.218 eth0
Unicast reply from 192.168.0.1 [aa:aa:aa:aa:BF:38] 0.667ms
Unicast reply from 192.168.0.1 [aa:aa:aa:aa:BF:38] 0.650ms
Arping na bránu ze serveru co dělal problémy
arping 192.168.0.1
ARPING 192.168.0.1
60 bytes from aa:aa:aa:aa:bf:38 (192.168.0.1): index=0 time=291.109 usec
60 bytes from aa:aa:aa:aa:bf:38 (192.168.0.1): index=1 time=167.131 usec
Stejné výsledky jsou i z ostatních PC v síti. Kdyby se v síti nacházel stroj se stejnou IP, MAC adresa by byla při pingu jiná. Podotýkám, že když nefungovalo spojení s bránou arping fungoval, viz výše. A navíc arping funguje pouze v daném subnetu. Nebo se pletu?
Tiskni
Sdílej: