Archiv rubriky: Linux

Netplan a nastavení IP podle MAC adresy

Už se vám také stalo, že serveru na Ubuntu 18.04 nastavíte IP adresu přes netplan a po restartu se síťové karty jmenují jinak, a tak se IP správně nenastaví?

Dříve se to dalo řešit pomocí nastavení /etc/udev/rules.d/70-persistent-net.rules. Z nějakého důvodu mi to ale v mém případě nefungovalo. Nefungovalo ani nastavení net.ifnames=0 biosdevname=0 do GRUB_CMDLINE_LINUX, systém pak nechtěl bootovat. Co dál?

Naštěstí se to dá vyřešit i pomocí netplan. Místo využití jména síťovky použijeme její MAC adresu:

network:
  version: 2
  ethernets:
    wan:
      match:
        macaddress: 00:XX:XX:XX:XX:XX
      set-name: wan
      dhcp4: no
      addresses: [192.168.1.100/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1,1.0.0.1]

Dříve mě výměna klasického nastavení sítě přes /etc/network/interfaces za netplan vadila. Dnes jej však shledávám užitečným nástrojem, ve kterém se dá snadno nastavit spousta věcí. Doporučuji si jeho kompletní nastavení prostudovat.

Dodatek

Narazil jsem na chybu, která se projeví právě při přejmenování ethernetového rozhraní přes netplan. Chyba je více zdokumentována zde. Dá se obejít tak, že se rozhraní pojmenuje pomocí systemd. Vytvoříme soubor např. /etc/systemd/network/10-wan.link s obsahem:

[Match]
MACAddress=00:XX:XX:XX:XX:XX

[Link]
Name=wan

Systém pak aktualizujeme příkazem update-initramfs -u. V netplan pak není potřeba rozhraní přejmenovávat a jen mu nastavíme IP adresu.

Jak nastavit správná práva PHP sessions složce

Složka /var/lib/php/sessions, kde se standardně ukládají session soubory PHP, má poněkud nezvyklá práva drwx-wx-wt. V Linuxu je nastavíme následovně:

$ chmod 1733 /var/lib/php/sessions

Pokud bychom chtěli složku snadno v jednom kroku prohodit za novou, prázdnou, vypadal by příkaz náledovně:

cd /var/lib/php && mkdir new && chmod 1733 new && mv sessions old && mv new sessions

Jak spustit dvě instance Redis v Ubuntu 16

Po přechodu Ubuntu na SystemD je práce se službami trochu složitější a návod pro SystemD jsem nikde nenašel. V tomto návodu si pro přehlednost přejmenujeme původní instanci Redisu s příponou dle jejího portu a přidáme druhou instanci s inkrementovaným portem.

Nejprve Redis odebere ze spuštění, aby nám nikde nestrašil. Redis dále poběží, instance budeme prohazovat až později.

$ systemctl disable redis-server.service
$ update-rc.d redis-server remove

Nyní nakopírujeme systemd definice našich nových instancí.

$ cd /etc/systemd/system
$ cp /lib/systemd/system/redis-server.service redis-server-6379.service
$ cp /lib/systemd/system/redis-server.service redis-server-6380.service

V definicích upravíme cesty ke konfiguraci a PID file a odebereme Alias.

[Service]
ExecStart=/usr/bin/redis-server /etc/redis/redis-6379.conf
PIDFile=/var/run/redis/redis-server-6379.pid

Nakopírujeme také konfiguraci Redisu.

$ cd /etc/redis
$ cp redis.conf redis-6379.conf
$ cp redis.conf redis-6380.conf
$ chown redis:redis redis-*.conf

Upravíme konfiguraci.

port 6379
dir /var/lib/redis/6379
pidfile /var/run/redis/redis-server-6379.pid
logfile /var/log/redis/redis-server-6379.log

Vytvoříme datové složky.

$ mkdir /var/lib/redis/6379
$ mkdir /var/lib/redis/6380
$ chown redis:redis /var/lib/redis/63*

Provedeme reload systemd a prohodíme instance.

$ systemctl daemon-reload
$ systemctl stop redis-server.service
$ mv /var/lib/redis/*.* /var/lib/redis/6379/
$ systemctl start redis-server-6379.service

Běží Redis?

$ redis-cli -p 6379 info server | egrep "process_id|tcp_port|config_file"

Přidáme novou instanci po spuštění systému a původní zakážeme spustit. To nám zabrání, aby se původní instance s nově pojmenovanou bila o port.

$ systemctl enable redis-server-6379.service
$ systemctl mask redis-server.service

Spustíme a povolíme druhou isntanci.

$ systemctl enable redis-server-6380.service
$ systemctl start redis-server-6380.service

Běží druhá instance?

$ redis-cli -p 6380 info server | egrep "process_id|tcp_port|config_file"

Ještě si porty v systému pojmenujeme pro lepší přehled v Netstat.

$ echo "redis1  6379/tcp" >> /etc/services 
$ echo "redis2  6380/tcp" >> /etc/services
$ netstat -l | grep redis

Vlastní certifikační autorita pro přihlašování k SSH

Při přihlašování k SSH jste jistě již mockrát viděli hlášku, jako je tato:

The authenticity of host 'example.com (1.2.3.4)' can't be established.
RSA key fingerprint is 1b:9b:b8:5e:74:b1:31:19:35:48:48:ba:7d:d0:01:f5.
Are you sure you want to continue connecting (yes/no)?

Většinou ji napoprvé bezmyšlenkovitě potvrdíme a všímáme si jí pouze v případě, že se objeví znovu. Značí to, že je něco špatně. Jak se ale této hlášce vyhnout úplně? Ověřování fingerprintu jistě nechceme vypnout, to by nebylo moc bezpečné 🙂 Jak tedy na to jinak? Založíme si pro SSH vlastní CA!

Nejprve si musíme vygenerovat podepisovací klíč.

$ mkdir .ssh/ca
$ cd .ssh/ca
$ ssh-keygen -t ed25519 -C ca@example.com -f ca.ed25519
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ca.ed25519.
Your public key has been saved in ca.ed25519.pub.
The key fingerprint is:
SHA256:J3nD9rV49uE57+2w79GeMKw1+jfZeEcc6crNjFdfXeg ca@exmaple.com
The key's randomart image is:
+--[ED25519 256]--+
|                 |
|                 |
|               ..|
|         o    .o.|
|        S *  .o.+|
|         = o.oEoB|
|            +*@=B|
|            +**#@|
|           o..+X#|
+----[SHA256]-----+

Příkaz nám vygeneroval dva soubory ca.ed25519 a ca.ed25519.pub. Ukážu zde pouze generování pro algoritmus ED25519, pro jiné algoritmy je postup obdobný.

Nyní potřebujeme veřejný klíč serveru, ke kterému se budeme přihlašovat. Ten pak podepíšeme a podepsaný klíč nahrajeme zpět na server.

$ scp example.com:/etc/ssh/ssh_host_ed25519_key.pub .
$ ssh-keygen -s ca.ed25519 -I example.com -h -n example.com -V +156w ssh_host_ed25519_key.pub
Signed host key ssh_host_ed25519_key-cert.pub: id "example.com" serial 0 for example.com valid from 2017-03-03T17:57:00 to 2020-02-28T17:58:38
$ scp ssh_host_ed25519_key-cert.pub example.com:/etc/ssh/

Nyní bude potřeba říct o novém certifikátu SSH serveru. Přidáme do /etc/ssh/sshd_config jeden řádek a restartujeme SSH.

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Nyní můžeme na všech počítačích, které se potřebují k serveru přihlašovat, přidat do ~/.ssh/known_hosts veřejný klíč naší nové CA.

@cert-authority *.example.com 

SSH se již nebude ptát na potvrzení fingerprintu. Pokud soubor přidáváe na počítač, ze kterého jste certifikáty kopírovali, máte již cílový server v known_hosts přidaný. Musíme jej tedy ještě vymazat.

$ ssh-keygen -R example.com
# Host example.com found: line 3
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old

Jak bezpečně distribuovat hesla v gitu

Pokud už jste někdy rozcházeli deployment aplikace pomocí gitu, asi jste narazili na problém, jak na produkční server bezpečně dostat hesla. Mít je v plaintextu v GITu moc bezpečné není 🙂 Přesto ale je způsob, jak je v gitu mít bezpečně – zašifrovat je. Jak to udělat a jak je při deploymentu do produkce rozšifrovat?

Pokud nemáte, nainstalujte si na produkčním server GPG. Na Unbuntu/Debian se to dělá takto:

$ apt-get install gnupg

Pro generování klíčů budeme potřebovat hodně entropy, doporučuji tedy nainstalovat i Haveged, viz. můj minulý článek.

Nyní se potřebujeme přepnout pod uživatele, pod kterým probíhá deployment. V mém případě je to uživatel web. Pod tímto uživatelem vygenerujeme základní keypair. Důležité: nezadávejte při generování klíčů žádné heslo, jen volbu potvrďte entrem.

$ gpg --gen-key
gpg (GnuPG) 1.4.16; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory `/home/web/.gnupg' created
gpg: new configuration file `/home/web/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/web/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/web/.gnupg/secring.gpg' created
gpg: keyring `/home/web/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) "

Real name: Deployment User
Email address: web@mydomain.tld
Comment: Deployment User
You selected this USER-ID:
    "Deployment User (Deployment User) "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

You don't want a passphrase - this is probably a *bad* idea!
I will do it anyway.  You can change your passphrase at any time,
using this program with the option "--edit-key".

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++
...+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.+++++
.......+++++
gpg: /home/web/.gnupg/trustdb.gpg: trustdb created
gpg: key 6C791601 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   4096R/6C791601 2016-01-15
      Key fingerprint = B690 9E58 FA2C EAE6 008F  1A2E 88CD 1D28 6C79 1601
uid                  Deployment User (Deployment User) 
sub   4096R/BF95086E 2016-01-15

Teď když máme vygenerovaný keypair, vyexportujeme veřejný klíč, nejlépe do souboru:

$ gpg --armor --export web@mydomain.tld > public.key

To by bylo pro produkční server zatím vše. Nyní si na našem vývojovém stroji vygenerujeme keypair stejně jako na produkčním serveru. Tentokrát ale doporučuji zadat heslo, na které se se vás GPG při šifrování a dalších operacích bude ptát. Poté importujeme veřejný klíč produkčního serveru.

$ gpg --import public.key
gpg: key 6C791601: public key "Deployment User (Deployment User) " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Importovaný klíč podepíšeme, tím řekneme GPG, že důvěřujeme jeho původu:

$ gpg --sign-key web@mydomain.tld

pub  4096R/6C791601  created: 2016-01-15  expires: never       usage: SC  
                     trust: unknown       validity: unknown
sub  4096R/BF95086E  created: 2016-01-15  expires: never       usage: E   
[ unknown] (1). Deployment User (Deployment User) 


pub  4096R/6C791601  created: 2016-01-15  expires: never       usage: SC  
                     trust: unknown       validity: unknown
 Primary key fingerprint: B690 9E58 FA2C EAE6 008F  1A2E 88CD 1D28 6C79 1601

     Deployment User (Deployment User) 

Are you sure that you want to sign this key with your
key "Developer User (Developer User) " (1BDC2E07)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "Developer User (Developer User) "
4096-bit RSA key, ID 1BDC2E07, created 2016-01-15

gpg: problem with the agent - disabling agent use
Enter passphrase:

Teď přijde ta hlavní část. Zašifrujeme veřejným klíčem produkčního serveru konfigurační soubor s hesly:

$ gpg --output prod.conf.gpg --encrypt --recipient web@mydomain.tld prod.conf

Zašifrovaný soubor .gpg pak můžeme bez problémů commitnout do gitu. Bez privátního klíče produkčního serveru jeho obsah nikdo nepřečte. Na produkčním serveru pak v deployment procesu nastavíme rozšifrování tohoto souboru pomocí privátního klíče, který už na serveru máme.

$ gpg --output local.conf --decrypt prod.conf.gpg
gpg: encrypted with 4096-bit RSA key, ID BF95086E, created 2016-01-15
      "Deployment User (Deployment User) "

Jak zrychlit generování certifikátů v linuxu

Při generování certifikátů systém potřebuje tzv. entropy. Kolik jej systém aktuálně má můžete zjistit tímto příkazem:

$ cat /proc/sys/kernel/random/entropy_avail

Protože se entropy získává především z uživatelského vstupu, je s ním na serveru trochu problém. Tenhle problém řeší Haveged. Jak to celé pracuje je hezky vysvětleno v článku How to Setup Additional Entropy for Cloud Servers Using Haveged.

Jak vytvořit Ubuntu image pro SmartOS

Po nějaké době vás přestane bavit instalovat všechny nové VPS z ISO image. Nastal čas vytvořit si image pro imgadm. Jak na to?

Vytvoříme si prázdný VPS:

$ vmadm create <<EOF
{
	"alias": "ubuntu-14-04-3",
	"brand": "kvm",
	"autoboot": false,
	"vnc_port": 12300,
	"vcpus": 1,
	"ram": 1024,
	"cpu_cap": 100,
	"cpu_shares": 100,
	"zfs_io_priority": 100,
	"max_lwps": 2000,
	"quota": 10,
	"disks": [
		{
			"boot": true,
			"model": "virtio",
			"size": 10240

		}

	],
	"resolvers": ["8.8.8.8", "8.8.4.4"],
	"nics": [
		{
			"nic_tag": "admin",
			"model": "virtio",
			"ip": "x.x.x.x",
			"netmask": "255.255.255.0",
			"gateway": "y.y.y.y",
			"primary": true
		}
	]

}
EOF
Successfully created VM e736e906-5cca-49e8-a0e0-7a3367ee6841

Stáhneme instalační ISO a nabootujeme z něj VPS:

$ cd /zones/e736e906-5cca-49e8-a0e0-7a3367ee6841/root
$ wget -q http://releases.ubuntu.com/trusty/ubuntu-14.04.2-server-amd64.iso
$ vmadm boot e736e906-5cca-49e8-a0e0-7a3367ee6841 order=cd,once=d cdrom=/ubuntu-14.04.3-server-amd64.iso,ide
Successfully started VM e736e906-5cca-49e8-a0e0-7a3367ee6841

Získáme info o VNC a připojíme se na něj:

$ vmadm info e736e906-5cca-49e8-a0e0-7a3367ee6841 vnc

Nyní nainstalujeme Ubuntu (nebo jiný OS) jak jsme zvyklí. U ubuntu ještě doporučuji pomocí F4 zvolit volbu „Install a minimal virtual machine“.

Po instalaci uděláme aktualizaci systému a reboot:

$ sudo su
$ aptitude update
$ aptitude dist-upgrade
$ reboot

Po rebootu odstraníme staré kernely:

$ sudo su
$ dpkg -l|grep linux
ii  libselinux1:amd64               2.2.2-1ubuntu0.1                 amd64        SELinux runtime shared libraries
ii  linux-headers-3.19.0-25         3.19.0-25.26~14.04.1             all          Header files related to Linux kernel version 3.19.0
ii  linux-headers-3.19.0-25-generic 3.19.0-25.26~14.04.1             amd64        Linux kernel headers for version 3.19.0 on 64 bit x86 SMP
ii  linux-headers-3.19.0-26         3.19.0-26.28~14.04.1             all          Header files related to Linux kernel version 3.19.0
ii  linux-headers-3.19.0-26-generic 3.19.0-26.28~14.04.1             amd64        Linux kernel headers for version 3.19.0 on 64 bit x86 SMP
ii  linux-headers-generic-lts-vivid 3.19.0.26.13                     amd64        Generic Linux kernel headers
ii  linux-headers-virtual-lts-vivid 3.19.0.26.13                     amd64        Transitional package.
ii  linux-image-3.19.0-25-generic   3.19.0-25.26~14.04.1             amd64        Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii  linux-image-3.19.0-26-generic   3.19.0-26.28~14.04.1             amd64        Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii  linux-image-virtual-lts-vivid   3.19.0.26.13                     amd64        This package will always depend on the latest minimal generic kernel image.
ii  linux-virtual-lts-vivid         3.19.0.26.13                     amd64        Minimal Generic Linux kernel and headers
ii  util-linux                      2.20.1-5.1ubuntu20.6             amd64        Miscellaneous system utilities
$ aptitude purge linux-headers-3.19.0-25 linux-headers-3.19.0-25-generic linux-image-3.19.0-25-generic

Volitelně také můžeme vyhodit hlavičkové soubory, které ve většině případů nejsou potřeba, ale aktualizují se zbytečně s každým kernelem:

$ aptitude purge linux-headers-3.19.0-26 linux-headers-3.19.0-26-generic linux-headers-generic-lts-vivid linux-headers-virtual-lts-vivid linux-image-virtual-lts-vivid linux-virtual-lts-vivid

Můžeme doinstalovat nějaké balíky. Rozhodně ale nesmíme vynechat balík acpid:

$ aptitude install acpid arping htop mc

Některé přebytečné balíky se hodí vyhodit:

$ aptitude purge usbutils pppoeconf pppconfig ppp popularity-contest pciutils ntfs-3g laptop-detect apparmor libapparmor-perl

Dále nainstalujeme sdc-vmtools:

$ cd /usr/src
$ wget https://github.com/joyent/sdc-vmtools/archive/master.zip
$ aptitude install unzip
$ unzip master.zip
$ cd sdc-vmtools-master/src/linux
$ ./install-tools.sh -y
$ cd /usr/src
$ rm -r sdc-vmtools-master/ master.zip

Přihlásíme se přes VNC a ostraníme uživatele, kterého jsme vytvořili při instalaci systému:

$ sudo su
$ passwd
# Relogin jako root
$ userdel user
$ rm -r /home/user

Připravíme VPS na vypnutí:

$ /lib/smartdc/prepare-image

Rootovi můžeme nyní odebrat heslo:

$ passwd -d root

Shodíme VPS a vratíme se do SmartOS:

poweroff

Vytvoříme z VPS image:

$ zfs create zones/images
$ zfs snapshot `vmadm get e736e906-5cca-49e8-a0e0-7a3367ee6841|json disks.0.zfs_filesystem`@final
$ zfs send `vmadm get e736e906-5cca-49e8-a0e0-7a3367ee6841|json disks.0.zfs_filesystem`@final | bzip2 --best > /zones/images/ubuntu-14.04.3-server-amd64.zvol.bz2

A VPS smažeme:

$ vmadm destroy e736e906-5cca-49e8-a0e0-7a3367ee6841
Successfully deleted VM e736e906-5cca-49e8-a0e0-7a3367ee6841

Pro image potřebujeme vytvořit dsmanifest:

cd /zones/images
cat > ubuntu-14.04.3-server-amd64.dsmanifest <<EOF
{
	"uuid": "`uuid`",
	"creator_name": "organizace",
	"creator_uuid": "ef16d6fc-51a7-11e5-8793-67c0a6dc6ee3",
	"vendor_uuid": "ef16d6fc-51a7-11e5-8793-67c0a6dc6ee3",
	"name": "ubuntu64",
	"version": "14.04.3",
	"urn": "sdc:organizace:ubuntu64:14.04.3",
	"type": "zvol",
	"os": "linux",
	"description": "Ubuntu 14.04.3 LTS Server x86-64 VM image",
	"created_at": "2015-09-02T21:14:00Z",
	"updated_at": "2015-09-02T21:14:00Z",
	"files": [
		{
			"path": "ubuntu-14.04.3-server-amd64.zvol.bz2",
			"sha1": "`shasum ubuntu-14.04.3-server-amd64.zvol.bz2|awk '{print $1}'`",
			"size": `ls -l ubuntu-14.04.3-server-amd64.zvol.bz2|awk '{print $5}'`
		}
	],
	"image_size": "10240",
	"requirements": {
		"networks": [
			{
				"name": "net0",
				"description": "public"
			}
		],
		"ssh_key": true
	},
	"platform_type": "smartos",
	"cloud_name": "sdc",
	"cpu_type": "host",
	"disk_driver": "virtio",
	"nic_driver": "virtio",
	"generate_passwords": "true",
	"users": [
		{"name": "root"}
	]
}
EOF

UUID pro creator_uuid a vendor_uuid si můžete vygenerovat příkazem uuid.

Máme image a dsmanifest, teď image můžeme nainstalovat:

imgadm install -m ubuntu-14.04.3-server-amd64.dsmanifest -f ubuntu-14.04.3-server-amd64.zvol.bz2

A teď z image konečně vytvoříme VPS:


Nemá smysl dávat disku větší size, než je size image. Disk se stejně vytvoří podle image. Prozatím to řeším pomocí GParted. Jakmile budu vědět, jak to zautomatizovat, napíšu o tom další článek. Nebo můžete někdo poradit v diskuzi pod článkem 🙂

Dodatek: dá se to řešit takto:

# V global zóně
$ zfs set volsize=54G zones/7dc89552-48fd-4fb7-9dfa-470ee47502b3-disk0
# Ve VPS
$ fdisk /dev/vda

Command (m for help): d
Selected partition 1

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-113246207, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-113246207, default 113246207):
Using default value 113246207

# Reboot
$ resize2fs /dev/vda1
# Reboot

Jak přejmenovat soubor, aby tak po upgradu balíčku zůstal

Asi už vás někdy napadlo nějaký nešikovný název programu v linuxu přejmenovat. To ale obvykle přináší jeden malý problém. Je potřeba to udělat po každém upgradu onoho programu. Distribuce založené na Debianu (tedy i Ubuntu) na to mají naštěstí fígl. Program dpkg-divert vám dovolí přejmenovat nebo nalinkovat soubor jinam a ten bude po upgradu balíku takto udržován.

Příkaz pak vypadá např. takto:

dpkg-divert --local --divert /usr/bin/ack --rename --add /usr/bin/ack-grep
  • Parametr –local zajistí, že přejmenování zůstane pro všechny verze balíčku
  • Parametr –divert říká, jak se bude program jmenovat
  • Parametr –rename zajistí přejmenování místo nalinkování souboru
  • Parametr –add říká, který soubor vlastně přejmenováváme

Možnosti nasazení CEPH s ProxmoxVM a Ubuntu VPS

CEPH je velice zajímá technologie kombinujcí object storage, block storage a filesystem.

One Object Storage: The Ceph Object Store, called RADOS, is the object storage component for CephFS filesystems, Ceph RADOS Gateways, and Ceph Block Devices.

Many Storage Interfaces: You can use CephFS, Ceph RADOS Gateway, or Ceph Block Devices in your deployment. You may also use all three interfaces with the same Ceph Object Store cluster! There’s no reason to build three different storage clusters for three different types of storage interface!

Use Commodity Hardware!: You can deploy Ceph with commodity hardware. You don’t need to purchase proprietary storage or networking hardware commonly used in SAN systems.

Při testech jsem zjistil následující:

  • Pro testy je potřeba minimálně dvou OSD (nodů pro ukládání dat)
  • ProxmoxVE 2.2 kernel nemá modul rbd
  • Ubuntu virtual kernel nemá modul rbd
  • Proxmoxu ještě nějakou chvíli potrvá, než CEPH zařadí do svých balíků, zdali vůbec

CEPH si určitě zaslouží sledovat a testovat dál, ale v současném stavu bych jej v kombinaci s Proxmoxem nedoporučoval, pokud nechcete sami kompilovat a udržovat balíky.