Příspěvky

301

Windows a jiné systémy / Re:SRV záznam pro active directory

« kdy: 29. 05. 2020, 11:34:35 »

Provozuji něco podobného.
Ano, v domain.tld uděláš delegaci na sub (NS & glue A), a v rámci té sub to řídí celé samba a všechny ty SRV záznamy jsou v ní.
Do domain.tld si přidávám položku _kerberos IN TXT "SUB.DOMAIN.TLD", protože máme vše nad kerberosem a tak ať funguje dohledávání správne realm domény.

Pokud to namlátíš ručně přímo do domain.tld (čili ne jako sub.domain.tld), tak to nějak funguje, ale některé věci blbou. To jsem si už dříve ověřil. Pokud to máš v rámci toho domain.tld DNS serveru zadáno ručně vše správně s sub.domain.tld, tak to fuguje OK.

Mam to namlacene rucne do domain.tld. Ale je taky fakt, ze stanice maji jako prvni dns uvedeno AD a ne centralni dns...
Dikec, tak to mi usnadni migraci na nova DNS.

302

Windows a jiné systémy / SRV záznam pro active directory

« kdy: 29. 05. 2020, 09:30:49 »

Ahoj,

mam sambu AD jako sub.domain.tld. Na jake urovni musi byt nastaveny SRV zaznamy? Momentalne to mam na urovni domain.tld, nema to byt nahodou na urovni sub.domain.tld?

domain.tld mi spravuje dns na debianu.
sub.domain.tld mi spravuje samba AD ("internal dns").

Myslim si, ze by to melo byt takto:

1] na urovni domain.tld delegace zony sub.domain.tld smerem na samba AD (NS & A glue zaznamy)
2] v ramci sub.domain.tld na samba AD musi byt SRV zaznamy

Kdo vi presne?
Diky

303

Server / Re:Uzavření uživatele v domovském adresáři

« kdy: 28. 05. 2020, 12:43:18 »

Ano přesně to potřebuje. Právě jsem ale zjistil dost něšťastnou věc, že pokud mu zakážu shell, tak se mi nejde připojit přes WIN SPC. Musel jsem shell opět zapnout resp. nefunkční /usr/sbin/nologin nahradit funkčním /bin/sh.
Na ty odkazy kouknu.

Winscp bud pouziva scp (=vyzaduje shell) nebo sftp (=nevyzaduje shell asi)...

304

Sítě / Re:Interní IPv6 a domény ve veřejném DNS

« kdy: 25. 05. 2020, 09:33:10 »

Jeste zvazuji neco jako dnsdist (dns balancer) https://dnsdist.org/reference/dnsnameset.html

Momentalne mam k dispozici konfiguraci, ktera podle src IP posila na rekurzor nebo auth server. Ja bych si predstavoval predrazeni pred auth server s timto prubehem:

a] definice internich domen a in-addr.arpa
b] pokud jde request na a]:
b1] jsi z povolenych src ip -> predam na auth server
b] nejsi z povolenych src ip -> deny/nxdomain
c] pokud jde request na cokoli z mimo a] -> predam na auth server

Chovalo by se to podobne jako ACL v rekurzoru. Zna kdyztak nekdo neco obdobneho?

305

Server / Re:Debian 9 + Seafile + Modoboa server - dve domeny

« kdy: 24. 05. 2020, 11:54:49 »

Do /etc/hostname dejte hostname a do /etc/hosts dejte hostname.domain.tld, pricemz pouzijte jmeno fyzickeho stroje. Seafile a modoboa muzou byt virtualni domeny, ktere budou v dns ukazovat na fyzicky hostname.domain.tld.

Takze:
server: hostname.domain.tld
seafile: neco.domena.cz
modoboa: mail.domena.cz

v DNS:
neco.domena.cz -> CNAME -> hostname.domain.tld
mail.domena.cz -> CNAME -> hostname.domain.tld
domena.cz -> MX -> mail.domena.cz

306

Sítě / Re:Interní IPv6 a domény ve veřejném DNS

« kdy: 24. 05. 2020, 11:49:03 »

Servery, co jsou určené jen pro vnitřek, tak máme na IPv6 ULA adresách (fc00::/7) a jsou zavedeny jen v interním DNS. Servery, co jsou dostupné z venku (a občas i zevnitř) nebo mají právo navazovat přímo spojení ven do Internetu, tak mají klasické IPv6 globální adresy a jsou identicky vedeny ve veřejném i interním DNS. U IPv4 to máme stejně. A samozřejmě je to v různých VLAN (DMZ), odděleno firewally.
I stanice uvnitř mají jen IPv6 ULA adresy (spojení ven je možná pouze skrz aplikační proxiny).

No to je prave ono. Kvuli historii (bind s views) musim vest duplicitne jednu zonu v public i internim auth serveru. Kazdy asi tusi, jaky je to problem. Jak pak resite treba subdomeny?

priklad s ipv4:
server mel rfc1918 adresu s domenou host.sub.domain.tld. Nasmerovano na private auth. Problem solved

priklad s ipv6 (ipv4 hosti stale existuji):
server ma nyni ipv6 s host.sub.domain.tld

Pokud na resolveru nasmeruji sub.domain.tld na interni authoritative (protoze ipv4), tak se v kombinaci s ipv6 stane co?
Duplikace ipv6 adres pro tu sub.domaint.tld na public/private auth serveru... Navic u nas se zatim rozhodlo ULA nepouzivat - aby se nemuselo zase vsechno tahat pres nat/proxy.

Realne mi jde zhruba o tohle:
1] v public jsou rfc1918 ip4 -> je snadne ziskat ip/fqdn vsech ipv4 hostu v relativne kratkem case
2] v pripade ipv6 je 1] skoro nemozna, ale par info o nekterych siti se tim ziskat da

307

Sítě / Re:Interní IPv6 a domény ve veřejném DNS

« kdy: 24. 05. 2020, 11:32:17 »

Pokud máte tu možnost, dával bych vše do veřejné DNS. Pak můžete třeba bez problémů vystavovat důvěryhodné certifikáty přes ACME (Let's Encrypt). Můžete zvážit filtrování a záznamy o privátních zařízeních používat jen v interní síti a nepublikovat je ven, ale připadá mi to jako zbytečná komplikace.

ACME bych do toho netahal, to ma svy problemy s nasazenim azaz. To filtrovani si predstavujete jak?

308

Sítě / Interní IPv6 a domény ve veřejném DNS

« kdy: 22. 05. 2020, 13:03:23 »

Ahoj,

nekdo z dns fundovanejsich - jak je to v soucasnosti s pohledem na existenci internich domen/ip adres ve verejnem dns?

Z hlediska ipv4 je to jednoduche, provozujeme interni servery, takze ve verejnem dns se to neobjevi. Pokud ale zacnu kombinovat s ipv6...

Problem nastava s ipv6. Protoze adresa muze byt pouzita jako verejna ci neverejna (blokace firewallem). Ano, muzu si urcit jednu /56 jako verejne pristupnou, druhou /56 jako privatni pouziti, ale drive nebo pozdeji narazim na to, ze privatni sluzba ma byt verejnou, takze mam dve moznosti - jen nastavit firewall, nebo presunout sluzbu na verejnou ip z /56. Coz s sebou zase obnasi ruzna rizika, ze server je najednou v ruznych zonach, v kterych byt nemel (napr. prime propojeni typu "dmz" s "intranet" siti). Taktez to znamena pripadny provoz jako u ipv4 - jedny authoritative pro verejne, druhe pro privatni domeny, vcetne toho, ze to musi resit i resolvery, na co se maji pripojovat.

Navic nase servery nebezi na bindu, takze view se nepouzivaji. Authoritative servery jiz neumoznuji blokovat interni domeny na zaklade ip adresy zdroje...

Nazory? Diky.

309

Server / Re:Debian 9 - po restartu nefunguje IPv6 konektivita

« kdy: 19. 05. 2020, 15:17:21 »

Co se tyce toho sytemd-networkd, tak ja to pouzivam takto:

/etc/network/interfaces:

Kód: [Vybrat]

auto lo
iface lo inet loopback

Kód: [Vybrat]

systemctl disable networking
systemctl enable systemd-networkd

Zbytek sitove konfigurace jiz obsluhuje systemd-networkd. Akorat dualstack v jednom interface.network nepouzivam, mam pro ipv4 a ipv6 samostatne sitovky(vlany), tak je pripadne potreba si s tim pohrat, pokud bych tam mel nejakou chybku.

Pro kazde ladeni je vhodne pouzit, aby se odhalilo pripadne spatne nastavene routovani, cili chyba v konfigu:

Kód: [Vybrat]

ip -4 a
ip -4 ro 
ip -6 a
ip -6 ro

Jeste bych upozornil, ze nekdy mi ipv6 sit nefungovala po restartu systemd-networkd, ale po rebootu to bylo ok.

310

Server / Re:Debian 9 - po restartu nefunguje IPv6 konektivita

« kdy: 19. 05. 2020, 13:43:17 »

Kód: [Vybrat]

allow-hotplug ens3
iface ens3 inet static
    address 83.167.252.162
    netmask 255.255.255.0
    gateway 83.167.252.1
    dns-nameservers 83.31.33.19 80.79.16.5
 
iface ens3 inet6 static
    address 2A01:0430:002E::162
    netmask 64
    
    up /sbin/ip -6 ro add default via 2A01:0430:002E::1 dev ens3
    down /sbin/ip -6 ro del default via 2A01:0430:002E::1 dev ens3

systemd-networkd:
ens3.network

Kód: [Vybrat]

[Match]
Name=ens3

[Network]
Address=83.167.252.162/24
Address=2A01:0430:002E::162/64
DNS=83.31.33.19
DNS=80.79.16.5

[Route]
Gateway=83.167.252.1
Destination=0.0.0.0/0

[Route]
Gateway=2A01:0430:002E::1
Destination=::/0

311

Server / Re:Debian 9 - po restartu nefunguje IPv6 konektivita

« kdy: 19. 05. 2020, 12:01:38 »

Dejte sem konfiguraci /etc/network/interfaces (pripadne zamente IP, ale hure se to pak hleda).

312

Sítě / Re:Propojení dvou subnetů skrz WAN

« kdy: 11. 05. 2020, 09:18:12 »

Protoze se na to ptate, tak stejne rozsahy nelze. Dejte tam VPN a jednu stranu na urovni VPN NATujte na odlisny rozsah.

313

Server / Re:Ansible - instalace balíčku a problém s uživatelem

« kdy: 20. 04. 2020, 08:36:55 »

jj, řešil jsem to, prostě si disk namountuješ do jiného adresáře, nainstaluješ postgres, přesuneš data, a pak vytvoříš symlink popřípadě mount.

Hm, mozne, ale ne hezke reseni. Pokud to neolivni prava v subdir/file, tak by to slo. Jen musi byt asi dobre podminky, nebot kdyz tu roli spustim opakovane, tak mit najednou root:root misto postgres:postgres neni to prave orechove, i kdyby to bylo na chvili...

314

Server / Re:Ansible - instalace balíčku a problém s uživatelem

« kdy: 20. 04. 2020, 08:35:18 »

jj, řešil jsem to, prostě si disk namountuješ do jiného adresáře, nainstaluješ postgres, přesuneš data, a pak vytvoříš symlink popřípadě mount.

Tu fazi od "presunes data" jsem delal rucne, toho se chci prave zbavit.

315

Server / Re:Ansible - instalace balíčku a problém s uživatelem

« kdy: 17. 04. 2020, 12:25:59 »

No to je prave vse ten problem. Co jsem se dival, tak systemove je postgres vzdy uid:112, ale guid je ruzny.

Takze kdyz mam role:
- mounts - mountuje disky
- postgresql - instaluje postgresql
- common - default system

Roli mounts potrebuji pro vice sluzeb. Takze pokud ji zavolam z common, aby pripojil vsechny disky (mountpointy v host_vars), uzivatele nemam. Defacto je ani v tu chvili neznam - musel bych je taky uvest v host_vars.
Pokud roli mounts zavolam z postgresql pred instalalci, tak mi zkusi namountovat treba i disky pro nfs. Opet problem  (nfs sluzba jeste nemusi byt nainstalovana). Takze varianta, ze bych nastavil uid:gid pri mountovani a instalace postgresql by na to vytvorila uzivatele taky pada, protoze guid neni stabilni.

Vsak kruci, nejak rozumne to musi byt resitelne, neni prece kazdy server bez extra mountu pro dane sluzby...Jestli je jedina cesta mit nadefinovaneho kazdeho uzivatele kvuli tem mountpointum (tedy vytvareni je mimo pkg installaci), tak je to smula...