Virtualizáció

Sziasztok!

Több helyre is lehetett volna tenni a kérdést, de talán itt a legjobb.

Androidon van egy termux (linux environment), szeretnék ezen mysqt futtatni, ami egy darabig működött, de aztán elromlott...
Van egy Fedora on termux megoldás, ami https://archive.fedoraproject.org/pub/fedora/linux/releases/29/Containe…
container imaget tesz elérhetővé termux (Android) alatt.
Ebben a konténerben telepítek egy mariadb és mariadb-server -t.
Elindítani már nem tudom a mysqld-t, mert az systemd-n keresztül kívánna (?) elindulni, de a systemd nem megy ilyenkor containerből.

A kérdés talán általánosan úgy szól, hogy containerből hogy kell service-t indítani?

Remélem nem mondok hülyeséget, de ez még nem docker, a docker image-t ebből lehet előállítani, de azt már termuxon nem lehet futtatni.

Üdv,
Róbert

Sziasztok,

Egy docker registry-t szeretnék beüzemelni self signed certificate-tel. A lépéseket a docker oldala alapján csináltam:

#!/bin/sh
fqdn=xxx.hu
ip=nn.mm.xx.zz
#creating CA (ca-key.pem)
openssl genrsa -aes256 -out ca-key.pem 4096
#creating CA (ca.pem)
openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
#creating server key (server-key.pem)
openssl genrsa -out server-key.pem 4096
#createing cert signing request (server.csr)
openssl req -subj "/CN=${fqdn}" -sha256 -new -key server-key.pem -out server.csr
#sign public key with CA (server-cert.pem)
echo subjectAltName = DNS:${fqdn},IP:${ip},IP:127.0.0.1 >> extfile.cnf
echo extendedKeyUsage = serverAuth >> extfile.cnf
openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf
#create client key (key.pem)
openssl genrsa -out key.pem 4096
#create certificate signing request (client.csr)
openssl req -subj '/CN=client' -new -key key.pem -out client.csr

Ezután a doksi alapján a docker daemon-nal meg kellene etetni a certificate-et:

 dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:2376

Mivel nekem registry kell nem ezt kellene használnom, hanem a docker registry-t kellene indítani:

docker run -d \
  --restart=always \
  --name registry \
  -v /srv/registry/security:/certs \
  -v /srv/registry/data:/var/lib/registry \
  -e REGISTRY_HTTP_ADDR=0.0.0.0:5000 \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/cert.pem \
  -e REGISTRY_HTTP_TLS_KEY=/certs/server-key.pem \
  -p 5000:5000 \
  registry:2

Ez persze egy másik doksiból származik de csak két file-t kér. Ha elindítom és kérek egy logot, akkor azt mondja, hogy:
private key does not match public key

mit rontok el?

Suliban windows-os (win10 x64) gépeken szeretnénk fejlesztő játékokat futtatni. Szükség lenne egy Android 7.1 környezetre, ill. play áruház stabil működésére.
Mit ajánlanátok? Emulátort? Ha igen milyet? Virtuális gép? Milyen image? Kinek milyen tapasztalatai vannak? Mit érdemes? Természetesen free megoldásokat preferálnék.
Köszönöm!

Sziasztok!

A napokban kellett újratelepítenem egy szervert, amin futott egy Virtualbox 5.0 + Phpvirtualbox 5.0.5, ami szépen működött is.
Az újratelepítést követően Virtualboxbol a 6.0-t tettem fel, Phpvirtualboxbol pedig továbbra is az 5.0.5-öt, de mivel nem egészen működtek együtt kompatibilisen, ezért kipróbáltam a phpvirtualbox developer editiont, amivel már tudtam virtualis gépet létrehozni, és beállítani a specifikációját, viszont csatlakozni hozzá , sem console-on keresztül, sem remote desktoppal nem tudok.

Console-on való csatlakozáskor , ez a hibaüzenet fogad:

Disconnect reason: E: TCP: SECURITY_ERROR Error #2048

Remote Desktop esetén pedig visszautasítja a kapcsolatot a pc, amihez csatlakozni szeretnek.

Próbáltam , ssh tunnelen keresztül csatlakozni a 127.0.0.1:rdpport címen, consoleon, illetve rdp kliens használatával, de nem jártam sikerrel.

Tűzfalon mind a 3 lánc Accepten van.

Régebbi phpvirtualboxban ezzel a verziójú virtualboxal nem jutok odáig, hogy létrehozzak gépet, mert erro hibával leáll a storage létrehozásánál, így tesztelni sem tudom a console, vagy rdp elérést.

Van esetleg ötletetek, hogy , hogyan lehetne orovosolni a problémát, virtualbox downgrade nélkül?

A válaszokat és a segítségeteket előre is köszönöm!

Sziasztok. Egy kis problémám akadt egy Citrixes rendszerrel, amin egyedi alkalmazások futnak és .ica fájlokat letöltve lehet csatlakozni hozzájuk. Maga a háttér rendszer a storefront, netscaler és a többi úgy tűnik, hogy szépen üzemel. A netscaler logok alapján a végén csatlakozik is az appokat futtató számítógéphez. Sajnos a szerver, kliens logokban sem találhatóak error bejegyzések és a rendszerben sem történt nagyobb verzióváltás. Viszont nemrég kijött egy frissítés a kliens oldalról, amikor a Citrix Receivert felváltotta a Citrix Workspace az appok futtatásához. Jelenleg fel is van telepítve a legfrissebb aktuális verzió: 18.12.0.12. A hiba jelenség pedig úgy néz ki, hogy a letöltött .ica filet megnyitva egy pillanatra, felvillan valami és be is zárul avval a lendülettel. A gyártó oldalán nincs jelenleg evvel a verzióval kapcsolatban hozzá köthető bugok. Viszont a régebbi verziójú Citrix Receiverrel is hasonló jelenséget produkál. Valakinek van esetleg evvel kapcsolatban valamilyen jellegű tapasztalata vagy tippje, hogy mi okozhatja ezt? Köszönöm előre is a segítő hozzászólásokat.

ELK (Elasticsearch+Logstash+Kibana) stacket próbálok létrehozni Kubernetessel. Tisztán tanulási céllal, minden egy minikube VM-ben van, amiben van 25Gb tárhelye.

Amit szeretnék megcsinálni: Logstashel folyamatosan tölteni az adatokat Elasticsearchbe és Kibana-val megjeleníteni végül. Ezen belül skálázódást szeretném kipróbálni, pontosabban a konfigurációját, hogyan tudnám elérni, hogy valami mentén skálázódjon ez a setup. Amire elsőként gondoltam, hogy van egy ES master pod és több data pod, alapból 1Gb tárhellyel. Ha fogytán a hely, a saját autoscale konfigom csinál új data pod-ot és remélhetőleg innentől majd abba mennek az indexek. Így tovább egészen mondjuk 10-20 data pod-ig. Remélem eddig még nem hibás az elepelképzelés.

Ahol megakadtam: hiába van elég sok jó leírás és példa konfiguráció a neten, rögtön egy elég alap dolgot nem sikerült megértenem. Csináltam egy 20Gb-s PersistentVolume-ot. Ez a minikube

/usr/share/elasticsearch/data

könyvtárat használja. Ezek után megcsinálom a StatefulSet-et, ez lenne az, ami meg a megfelelő mennyiségű (egyelőre fix számú) data pod-ot létrehozza. Ennek a StatefulSet-nek a leírásába raktam a

volumeClaimTemplates

-et ami az előbbi PersistentVolume-ot hivatkozza, továbbá beállítottam, hogy 1Gb-t igényeljen pod-onként. Ez azt eredményezi, hogy 1 pod elkészül, az összes többi pedig pending állapotban marad mert nem talál a PersistentVolumeClaim-hez PersistentVolume-ot.

Kérdésem: a PersistentVolume-ok és PersistentVolumeClaim-ok között 1:1 megfeleltetés kell legyen? Ebben az esetben mi történik

/usr/share/elasticsearch/data

könyvtárban? Esetleg csináljak 20 könyvtárat minden egyes PersistentVolume-nak és ezek közül fognak majd "válogatni" a pod-ok mikor létrejönnek? Így kellene ennek működni, vagy alapból félreértettem a Kubernetes működését?
Köszönöm előre is a segítséget!

Sziasztok!

Érdekelne a véleményetek, tapasztalatotok!

A karácsonyi bejgli hatására eldöntöttem, hogy KVMről átnyergelek Docker-re.
Cél a production, stabilitást, "gondozás mentességet" szeretnék elérni, úgy ahogy az Debian Stable nyújtja a KVM-mel jelenleg.

Első és legfontosabb, hogy teljességgel zöldfülű vagyok a Docker és a production viszonylatában. magamnak már el mórickáztam vele localhost-on, de az messze van a prodtól.
Több domain hostolása a feladat, websiteok + levelezés. OpenVPN lenne még. Website-ok alá mongodb, mysql..de ezek az apró körítések már csak.
A DNS-t a domain regisztrátora adja.

Első kérdés:
Ki mit ajánl host os-nak bare metal-ra? ( HP DL360 gen6, 12 szál, 12Gb ram, 600Gb storage)

Ha nem muszály, ajánlott, javasolt cserélni, megtartanám a Debian Stable-t.
Ismerem, szeretem, és nem kell remote konzolt kérni a szerver újratelepítéséhez,(illetve Victor Hugo-ba fáradni) ha marad host-nak :D

Ubuntu, hát nem tudom, ( bizlmatlan vagyok, mióta a Cannonical kezd "el Microsoft-osodni" )

Ellenben a Fedora Atomic szóba jöhetne. Tetszik az OSTree megoldás alapvetően. Tudomásom szerint a RHEL8 már béta teszten van,
esetleg érdemes lenne kivárni még a Centos 8 kijön, sima, esetleg atomic verzióban? Fedora release "túl gyors" szerintem szerverként, a Centos 7 jelenleg meg
le van maradva mint a befőtt. Ugyan nem tudom Docker futtatása esetén ez mérvadó-e. Hiszen a konténerek 90%-a úgyis Alpine Linux, ott kell frissnek és szépnek lenni.

Ha már szóba jött, valakinek van szervere Alpine Linux-xal?

Csábító dolog a CoreOS, RancherOS is.

Második kérdés:
A docker áltat létrehozott hálózaton érdemes tovább tekerni, vagy megfelelő úgy ahogy van éles környezethez?
Gondolok itt elsősorban arra, hogy a konténerek ugye közzé teszik a saját kis portjaikat, amik ezáltal a publikus ip-n elérhetőek lesznek.
Érdemes-e inkább valamilyen saját vitruális hálózatot csinálni, amit aztán lehet farigcsálni kényem kedvem szerint, esetleg megfejelni valamilyen IPS/IDS megoldással,
ha van rá szükség, esetleg javasolt?

Harmadik kérdés(ek):
Kinek milyen tapasztalata van Postfix, Dovecot, MongoDB, OpenVPN futtatásával Docker konténerben?
Érdemes mások által már összeállított image-ekkel dolgozni, vagy jobb az ha az ember fia saját magának építi?

Üdv!
Proxy mögött hogyan lehetne használni?

$ docker build --build-arg http_proxy="http://proxy_ip:3128" -t centos7:test .
Sending build context to Docker daemon 3.072 kB
Step 1/8 : FROM centos:7
Trying to pull repository docker.io/library/centos ...
Trying to pull repository registry.fedoraproject.org/centos ...
Trying to pull repository quay.io/centos ...
Trying to pull repository registry.access.redhat.com/centos ...

Csak vár-vár... ztán timeout.

A doksi szerinti beállítás szerint sem akar kimenni:

$ export HTTP_PROXY=http://10.20.30.2:1234
$ export HTTPS_PROXY=http://10.20.30.2:1234
$ docker build --build-arg HTTP_PROXY --build-arg HTTPS_PROXY -t centos7:test .


Üdv!
Ha jól olvasom, akkor a Docker-ben nincs olyan bridge lehetőség, mint pl. az LXC-ben?
Tehát a hoszt gépen át kell irányítani portokat, csak úgy érhető el a Docker konténer kívülről?

Üdv!
Fedora 29 upgrade után nem indul semmi:

# rpm -q lxc
lxc-3.0.2-1.fc29.x86_64

uname -r
4.19.3-300.fc29.x86_64

# systemctl status lxc
● lxc.service - LXC Container Initialization and Autoboot Code
Loaded: loaded (/usr/lib/systemd/system/lxc.service; enabled; vendor preset: disabled)
Active: active (exited) since Sat 2018-11-24 19:01:15 CET; 56s ago
Docs: man:lxc-autostart
man:lxc
Process: 12642 ExecStop=/usr/libexec/lxc/lxc-containers stop (code=exited, status=0/SUCCESS)
Process: 12645 ExecStart=/usr/libexec/lxc/lxc-containers start (code=exited, status=0/SUCCESS)
Process: 12644 ExecStartPre=/usr/libexec/lxc/lxc-apparmor-load (code=exited, status=0/SUCCESS)
Main PID: 12645 (code=exited, status=0/SUCCESS)

nov 24 19:01:15 fedoranb systemd[1]: Starting LXC Container Initialization and Autoboot Code...
nov 24 19:01:15 fedoranb lxc-containers[12645]: Failed to load config for centos7-srv
nov 24 19:01:15 fedoranb systemd[1]: Started LXC Container Initialization and Autoboot Code.

A régi konténerek kuka? Az lxc-update-config sem segít.

Újat lértrehozni is csak az lxc.net beállítások kihagyásával enged.