Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Nová témata / Re:Pihole in docker container with network_mode host doesn't work
« Poslední příspěvek od SilverHead kdy Dnes v 20:45:01 »
https://github.com/pi-hole/docker-pi-hole/tree/master
section Quick start states:
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      - "80:80/tcp"
2
Nová témata / Re:Pihole in docker container with network_mode host doesn't work
« Poslední příspěvek od congo kdy Dnes v 20:38:48 »
odhliadnuc od ineho :
"As per suggestion"
koho suggestion ?
3
Server / Re:Pořízení domácího serveru na Proxmox
« Poslední příspěvek od skopda kdy Dnes v 20:32:24 »
Já jsem si stavěl domací proxmox server před rokem, nároky byli trochu nižší, ale s volbou jsem spokojený.
Desktopové Intel coffe lake cpu, micro atx deska asrock H370 chipset, 32 GB ram, 2xSSD v raid pro boot a 2x3,5" disky pro nas. napájí to PicoPSU a 12V adaptér. Celé je to chlazené jen jedním 120mm větrákem noctua. IPMI jsem nikdy nepotřeboval, proxmox funguje spolehlivě. žere to v idle když stojí disky pod 10W, při běžném provozu kolem 25W, max 60W. Pokud stojí disky tak je server téměř neslyšný. výkonový nárůst oproti starému atomu J1900 byl obrovský.
4
/dev/null / Re:Aky kavovar pre dobru kavu?
« Poslední příspěvek od ogdru6jahad kdy Dnes v 20:25:33 »
mi se libi originalni tema :-)

vsichni v praci jedou na kafe, ale ja jedu na dobre sypane caje, ktere mame v praci, doma jedu na pytlikove caje :-)
a kdyz jednou za pul roku vypiju kafe tak je to bazen a na tretiny je v tom cerne kafe, mliko a cukr.

a u pocitace popijim i pivo :-)
5
/dev/null / Re:Aky kavovar pre dobru kavu?
« Poslední příspěvek od leopmeps kdy Dnes v 20:01:12 »
Ahoj,

Virtualizace na Windows může být trochu náročná, zvlášť když chceš používat VMware a Hyper-V současně. Bohužel, jak už bylo zmíněno, VMware a Hyper-V se často „bijí“, protože oba používají různé technologie pro virtualizaci. Hyper-V při spuštění zamkne hardware a tím znemožní VMware přístup.

Pokud potřebuješ používat VMware Workstation a zároveň mít aktivní Hyper-V, jednou z možností je zapnout kompatibilní režim pro Hyper-V ve VMware Workstation. Postup:

Otevři VMware Workstation.
V nastavení virtuálního stroje jdi na „Compatibility“.
Vyber možnost „Virtualize Intel VT-x/EPT or AMD-V/RVI“, pokud je dostupná.
Další možností je dočasně vypnout Hyper-V, pokud zrovna nepracuješ s Dockerem nebo jinými nástroji, které Hyper-V vyžadují. To můžeš udělat příkazem v příkazové řádce s oprávněním administrátora:

vbnet
Skopiuj kod
bcdedit /set hypervisorlaunchtype off
Pro opětovné zapnutí Hyper-V:

arduino
Skopiuj kod
bcdedit /set hypervisorlaunchtype auto
Po změně je nutné restartovat počítač. Tímto způsobem můžeš přepínat mezi VMware a Hyper-V, ale není to zrovna pohodlné řešení.

Pokud chceš oba nástroje používat současně bez nutnosti restartu, zvážil bych přesun na Linux jako hostitelský systém a používat oba systémy na něm pomocí KVM, který je v Linuxu dobře integrovaný a podporuje různé hypervisory.

Více na https://gastromania.sk/profesionalne-kavovary
6
Nová témata / Pihole in docker container with network_mode host doesn't work
« Poslední příspěvek od SilverHead kdy Dnes v 19:38:13 »
hi guys,
omlouvam se za anglictinu ale nez bych se vymacknul cesky...


I run Fedora 40 on Raspberry Pi 4 with Docker(not Podman). I'd like to use Pihole as my DHCP and DNS.

I deploy with Docker compose. As per suggestion I use network_mode host instead of port expose. None of the ports binded to Pihole are opened outside of raspberry pi.

Let's focus on a basic example with webgui:

honza@silverhead-pi:-# ss -tlnp | grep 80

LISTEN 0 1024 192.168.1.4:80 0.0.0.0:*
LISTEN 0 1024 127.0.0.1:80 0.0.0.0:*
LISTEN 0 1024 [::]:80 [::]:*

honza@silverhead-pi:nmap -p 80 192.168.1.4
PORT STATE SERVICE 80/tcp open http

nmap from another device:

nmap -Pn -p 80 192.168.1.4
PORT STATE SERVICE 80/tcp closed http

Please note:
1) Connection to an independent Cockpit service port tcp/9090 from another device via network works like a charm.
2) Connection to port tcp/80 from another device via network works if I use default docker networking and port publish - aka it's not router firewall problem.


Here is my docker compose file:

name: pihole

services:

  pihole:

container_name: pihole

hostname: pihole

image: pihole/pihole:latest

network_mode: host

environment:

TZ: 'Europe/Stockholm'

WEBPASSWORD: 'kaBziz-foskik-5raste'

DNS1: '1.1.1.1'

DNS2: '1.0.0.1'

WEB_BIND_ADDR: '192.168.1.4'

cap_add:
NET_ADMIN
restart: unless-stopped

I doublechecked:

1) iptables and ip6tables input chain is in mode ACCEPT. I added a specific rule for tcp/80 on 192.168.1.4 - I see incoming requests
2) I dissabled selinux enforce just to make sure
3) there is zero activity in lighttpd logs in container - I checked /var/log/lighttpd/*
4) I can see incoming packets with manually installed tshark on port 80 inside the container
5) lighttpd forward configuration contains 192.168.1.4 IP
6) IPv6 behaves in similar way

expected result: access to webgui of pihole
What am I missing? it has to be something simple stupid :'( :-X

thank you
7
Sítě / Re:CETIN - připojení bytu
« Poslední příspěvek od LukePole kdy Dnes v 19:37:42 »
Mít rychlé a stabilní připojení k netu dneska nutnost pro většinu lidí je, to je prostě nepopiratelná realita, stejně jako má většina lidí vodu, elektriku, plyn, auto a mobilní telefon. A pokud takové připojení k netu nemají a jsou díky nesmyslným zákonům odkázáni na 30 let staré zvonkové dráty (DSL 20/2) nebo jednu BTS za kopcem (LTE ve dvou pásmech), o kterou se dělí 5 vesnic, tak jejich "nadšení" bych rozhodně sdílet nechtěl.
Jinak na ulici mně mnohem víc - než nějaké dráty na sloupech - vadí soustavně štěkající čokli, jejichž "produkty" jsou posety okolní trávníky a smrad hlavně v létě je neuvěřitelný, případně stojící a smrdící kontejnery a popelnice a další podobné obtěžující věci. Ne kabel kdesi 5m vysoko, který přestanu vnímat po pár dnech po instalaci, protože mě nijak neobtěžuje. A i kdyby na té ulici žádný kabel venku nebyl, tak stejně tam budou stát minimálně sloupy veřejného osvětlení, takže něco tam bude vždycky. Úplně čistá ulice neexistuje.
8
Hardware / Re:Nový monitor na práci vývojáře
« Poslední příspěvek od JurajP kdy Dnes v 19:17:50 »
A neviem ci by som asi chcel oled, nakolko tam je problem vypalovania pixelov, ktory moze vzniknut
9
Sítě / Re:CETIN - připojení bytu
« Poslední příspěvek od Martin Poljak kdy Dnes v 19:09:05 »
Jelikož si tady někteří Čecháčci naivně myslí, že když je vedení v zemi, tak se to rovná Ráji na Zemi a vůbec jim nedochází, že celou tu ekonomicky náročnou šaškárnu nakonec zatáhnou z vlastní kapsy...

No a? Já s tím problém nemám. Ano, ve výsledku někdy optika pod zemí může znamenat žádná optika. Ale ani s tím problém já osobně nemám. To není žádní existenční ani existenciální nutnost. Za tu nezadrátovanou ulici mi to stojí. Ono ne všechno se dá jednoduše odbýt penězi. Pořád je to můj domov. Ten nekončí za dveřmi mého domu.
10
Nová témata / QEMU nad LVM problem s deadlockem?
« Poslední příspěvek od RDa kdy Dnes v 18:49:04 »
Ahoj, posledni dobou se me deje podivna vec - QEMU proces se zasekne v neprerusitelnem sleepu (top: D state).

Konfigurace stacku je tahle:

- gentoo linux 6.11.0
- md raid1 mirror (hdd+ssd)
- lvm (pv/vg/lv)
- losetup ( posun o 1 sektor )
- qemu (9.0.2)
- winxp

Kdyz se to zasekne, tak nefunguje ani RDP z guestu (winxp), a celkove Qemu zhebne (nefunguje ani remote spice klient - a ani pripojeni na lokalni monitoring socket).

A co vic, nefunguje ani lvs prikaz na vypsani logical volumes. Proste taky D state a zasekne se.

strace lvs - me rikal posledne, ze to pouziva async io.. tak jsem podezrival tohle - pridal jsem do qemu option na disk ve tvaru ,aio=threads, ale neni s tim rozdil. Po tydnu se to ted seklo zas.

Stav je to docela neprijemny, protoze se host os neda vypnout ani restartnout - musim shodit ostatni VM, vsechny sluzby a pak to navrdo resnout, doufajic, ze systemovy oddil prezije (zatim nizsi jednotky tvrdych resetu to dalo... ext4 nad lvm).

Mam podezreni ze se sekne nejake uzamykani v jadre - ale netusim kde se divat.

Na starem jadru co tam bylo predtim to nedelalo zadny problem, ale to tam vracet nechci (6.6.52), plus byla nejaka podstatna zmena konfigurace, abych novym jadrem pokryl a sjednotil vicero stroju.

Jak by jste ladili takovou vec, co se objevi jednou za tyden? (tedy, pred tydnem jsem to potkal asi 3x v rade prvni den.. pak vznikl dodatek qemu konfigurace s aio=threads)

v lsof nejak nepoznam, na ktery fd to delalo jakou operaci? nebo jinde v sysfs? Neco jako show in-flight syscalls ?

Je fakt blby ze neni nejaky unlocker, na tyhle kernel-side locknute IO.
Klidne za cenu ze ta aplikace dostane error, spatna data nebo bude ukoncena v momente navratu syscallu.

EDIT:
pridal jsem sysrq podporu do jadra, az to padne priste at muzu udelat ten w command:
https://www.suse.com/support/kb/doc/?id=000016919
Stran: [1] 2 3 ... 10