Linux-haladó

Egy saját eszköz tesztelésében szeretném a segítségeteket kérni: egy backup szkriptről van szó, egy új (én legalább is nem találtam ilyet) megközelítéssel.

Github URL:
https://github.com/vbence/osbackup

Röviden: a program célja, hogy minél gyorsabban egy működő rendszer álljon fel (akár csak egy image-alapú módszernél), viszont az image-hez képest jóval kevesebb erőforrásigénnyel (lemezterület/átvitel).

A módszer, hogy a blockdevice-okról összegyűjtött metaadat alapján gyártunk egy szkriptet, ami újrakreálja az adott struktúrát (partíciók, raid, lvm, luks); ezután csak ki kell gzippelnünk az eredeti tartalmat. Nagyjából minden egy nagy tar.gz-be kerül, kivéve amit az operátor exclude-olt, ezek tipikusan gyakran változó adatok, amire más backupot tipusú backupot használ.

Igyekeztem azokra a technológiákra szorítkozni, amiket egy Debian installer segítségével felépíthet az ember (nincs pl. NILFS agy ZFS támogatás).

Bármilyen észervételt szivesen várok.

(A restore szkriptek legyártathatók a fájlrendszer összetgz-se nélkül, ha az `osbackup` szkript végén kiremelitek a tar sort).

Sziasztok!
Sok kérdés van mostanában a ZFS-el kapcsolatban és mi mindenre jó a karácsony ha nem egy kis tesztelésre. A ZFS nekem is egy új dolog a gyakorlatban, ezért gondoltam végzek egy kis tesztet. Mindent alapértelmezett beállításokkal teszteltem.A teszt masina egy VirtualBox VM:
- 1cpu
- 1GB RAM
- 1x8GB HDD Debian 7 alap install
- 2x8GB a tesztelésekre
minden más alapbeállításon
A host:
Intel Core2Duo 2,66GHz processzor
4GB RAM
1TB WD10EARS merevlemez

Ide jönne a táblázat, de nem találtam a megfelelő kódot ezért feltettem az eredményeket Google Drive-ra
https://docs.google.com/spreadsheets/d/1HFpQo4BMIaiGB-4E0vSgrPQeHAmiIwi…

Kíváncsi vagyok a véleményekre azoktól elsősorban, akik már használták a ZFS-t. Az én kis tesztem eredménye elég silány lett. Hangsúlyozom még egyszer,hogy minden teszt mindenféle külön hangolás nélkül készült. A teszt igazából egy téma indítására szolgál, nem jó vagy rossz színben feltüntetni valamit.

Az alap ötlet az,hogy szerver csere lesz egy Web/DNS/FTP/Mail szerver alatt és gondoltam ,hogy mi lenne ha ZFS-t tennék alá.

Kérdés azokhoz akik jobban értenek a ZFS-hez: Mi okozza ezt a gyenge teljesítményt? Milyen hangolási javaslatok vannak esetleg?

Kellemes Karácsonyt Mindenkinek! :)

Sziasztok!

Adott egy 32 Gigás USB 3.0 pendrive (Kingston).
Folyamatos olvasás 71 MB/s
Folyamatos írás 35 MB/s
Random olvasás 1192 IOPS
Random írás 277 IOPS

Azt tudom, hogy rövidtávon biztos jól lehetne Live Linux célokra használni, de most a kérdés az, hogy hosszútávon mennyire jó ötlet az ilyesmi? 10-ből 9 alkalommal ugyanabban a gépben kellene bootolnia, de a 10. alkalommal, már lehet, hogy random helyen használnám. Azon kívül, hogy a rendszer le lenne jelszavazva, nyilván szükséges még a titkosítás, hiszen nem szeretném, ha egyszerűen felcsatolva lehetne nyúlni róla az adatokat.

- Mit szól ehhez a pendrive élettartamban?
- Milyen titkosítást lehet/érdemes használni?
- Milyen fájlrendszert ajánlotok?
- Milyen egyéb beállításra, protipre lehet még szükségem?

Nem szempont, hogy x64-en kívül menjen (32-bites gépben nem lesz), és ha ez számít, akkor a preferencia sorrendben OpenSUSE, Linux Mint, Ubuntu.

Van-e ilyesmivel tapasztalatotok?

Szerk.: Van elég válasz ahhoz, hogy ne erőltessem a dolgot, köszönöm.

Üdv!

Hogyan tudnám a cx231xx drivert lefordítani a kernelhez?
A "make menuconfig"-ban be kellene valahol kapcsolnom. "Multimedia Support" -> Media USB Adapters -> Conexant cx231xx USB video capture support"
Tudna segíteni valaki, hogyan kellene ezt lefordítanom? A "make M=drivers/....." kellene?

(A kernel-devel, kernel-headers fent van.)

--
G.

Üdv!

Ez alapján próbálom a TFT kijelzőt meghajtani:
https://sites.google.com/site/davidemadrisan/linux-embedded/pidora#TOC-…

A "make menuconfig"-ban beállítottam amit írt, el is mentette a .config fájlba.
A "make M=drivers/video/fbtft" parancsra ennyit ír:
Building modules, stage 2.
MODPOST 0 modules

A .ko modulok nem is jöttek létre persze. Mit hibáztam el?

--
G.

Üdv!

Van egy SD kártya (RPi raspbian van rajta), de nem tudok másik oprendszert felmásolni rá, mert azt mondja, hogy "írásvédett a fájlrendszer".
Linux, Win7 alatt se működik. RPi-be berakva megy a kártya és írható.
Mit tudok tenni? dd-vel a kártyáról csináltam mentést.

--
G.

Üdv!

Egy RPi B eszközön szeretnék teszt jelleggel egy gpio7-re kiküldeni "1"-et.
Ez alapján néztem: http://elinux.org/RPi_Low-level_peripherals#General_Purpose_Input.2FOut…
Illetve a GPIOClass minta alapján.

// GPIOTest.cpp
#include < iostream >
#include < unistd.h >
#include < errno.h >
#include < stdio.h >
#include < stdlib.h >
#include "GPIOClass.h"


using namespace std;

int main (void)
{

string inputstate,state;

state = "1";

GPIOClass* gpio7 = new GPIOClass("7"); //create new GPIO object to be attached to GPIO7

gpio7->export_gpio(); //export GPIO7

cout << " GPIO pins exported" << endl;

gpio7->setdir_gpio("out"); //GPIO7 set to output

cout << " Set GPIO pin directions" << endl;
while(1)
{
usleep(500000); // wait for 0.5 seconds
gpio7->getval_gpio(inputstate); //read state of GPIO7 input pin
cout << "Current input pin state is " < < inputstate < < endl;
cout << "Set pin state is... " < < state < < endl;
gpio7->setval_gpio( state ); // set GPIO7
}
cout << "Exiting....." << endl;
return 0;
}

A progi irja is, hogy "1" az állapota.

Egy kis multimeterrel próbáltam mérni jelszintet a GROUND és GPIO7 láb (pin25, pin26) között, de nem mutatott semmit (azaz 0V).
Mit rontok el?

--
G.

Sziasztok,

OOM utan ujraindult VM a kovetkezot mutatja:
$ last -5
*deleted pts/1 *deleted Tue Dec 16 04:16 - 04:16 (00:00)
*deleted pts/0 *deleted Tue Dec 16 04:05 still logged in
reboot system boot 2.6.18-371.8.1.0 Tue Dec 16 05:02 (00:-39)
*deleted pts/1 *deleted Tue Dec 16 03:31 - 03:31 (00:00)
*deleted pts/1 *deleted Tue Dec 16 03:30 - 03:30 (00:00)

$ date
Tue Dec 16 04:23:01 CST 2014

$ who -b
system boot 2014-12-16 05:02

$ date; last reboot; uptime
Tue Dec 16 04:25:07 CST 2014
reboot system boot 2.6.18-371.8.1.0 Tue Dec 16 05:02 (00:-37)
wtmp begins Mon Nov 3 20:48:29 2014

Nem ertem, hogy lehet minuszban az ora. elotte utanna minden remek, a reboot time meg minusz. A reboot utan kb 4. percben futtattam a fenti parancsokat.

Üdv!

Egy CentOS 6.5 ssh szerveren távolról Gnome Commander-el be lehet lépni. A MC Shell-kapcsolattal viszont nem.
Ez valami bug?
A logban ez van:

Dec 14 14:02:52 soma sshd[26382]: debug1: Forked child 28270.
Dec 14 14:02:52 soma sshd[28270]: Set /proc/self/oom_score_adj to -800
Dec 14 14:02:52 soma sshd[28270]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Dec 14 14:02:52 soma sshd[28270]: debug1: inetd sockets after dupping: 3, 3
Dec 14 14:02:52 soma sshd[28270]: Connection from 5.187.250.144 port 37234
Dec 14 14:02:52 soma sshd[28270]: debug1: Client protocol version 2.0; client software version OpenSSH_6.4
Dec 14 14:02:52 soma sshd[28270]: debug1: match: OpenSSH_6.4 pat OpenSSH*
Dec 14 14:02:52 soma sshd[28270]: debug1: Enabling compatibility mode for protocol 2.0
Dec 14 14:02:52 soma sshd[28270]: debug1: Local version string SSH-2.0-OpenSSH_5.3
Dec 14 14:02:52 soma sshd[28271]: debug1: permanently_set_uid: 74/74
Dec 14 14:02:52 soma sshd[28271]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Dec 14 14:02:52 soma sshd[28271]: debug1: SSH2_MSG_KEXINIT sent
Dec 14 14:02:52 soma sshd[28271]: debug1: SSH2_MSG_KEXINIT received
Dec 14 14:02:52 soma sshd[28271]: debug1: kex: client->server aes128-ctr hmac-md5 none
Dec 14 14:02:52 soma sshd[28271]: debug1: kex: server->client aes128-ctr hmac-md5 none
Dec 14 14:02:52 soma sshd[28271]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Dec 14 14:02:52 soma sshd[28271]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Dec 14 14:02:52 soma sshd[28271]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Dec 14 14:02:52 soma sshd[28271]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Dec 14 14:02:52 soma sshd[28271]: debug1: SSH2_MSG_NEWKEYS sent
Dec 14 14:02:52 soma sshd[28271]: debug1: expecting SSH2_MSG_NEWKEYS
Dec 14 14:02:52 soma sshd[28271]: debug1: SSH2_MSG_NEWKEYS received
Dec 14 14:02:52 soma sshd[28271]: debug1: KEX done
Dec 14 14:02:52 soma sshd[28271]: debug1: userauth-request for user myuser service ssh-connection method none
Dec 14 14:02:52 soma sshd[28271]: debug1: attempt 0 failures 0
Dec 14 14:02:52 soma sshd[28270]: debug1: user myuser matched group list sftpgroup at line 142
Dec 14 14:02:52 soma sshd[28270]: debug1: PAM: initializing for "myuser"
Dec 14 14:02:52 soma sshd[28270]: debug1: PAM: setting PAM_RHOST to "5bbfa8t.mobile.pool.telekom.hu"
Dec 14 14:02:52 soma sshd[28270]: debug1: PAM: setting PAM_TTY to "ssh"
Dec 14 14:02:57 soma sshd[28271]: debug1: userauth-request for user myuser service ssh-connection method password
Dec 14 14:02:57 soma sshd[28271]: debug1: attempt 1 failures 0
Dec 14 14:02:57 soma sshd[28270]: debug1: PAM: password authentication accepted for myuser
Dec 14 14:02:57 soma sshd[28270]: debug1: do_pam_account: called
Dec 14 14:02:57 soma sshd[28270]: Accepted password for myuser from 5.187.250.144 port 37234 ssh2
Dec 14 14:02:57 soma sshd[28270]: debug1: monitor_child_preauth: myuser has been authenticated by privileged process
Dec 14 14:02:57 soma sshd[28270]: debug1: SELinux support disabled
Dec 14 14:02:57 soma sshd[28270]: debug1: PAM: establishing credentials
Dec 14 14:02:57 soma sshd[28270]: pam_unix(sshd:session): session opened for user myuser by (uid=0)
Dec 14 14:02:57 soma sshd[28270]: User child is on pid 28272
Dec 14 14:02:57 soma sshd[28272]: debug1: PAM: establishing credentials
Dec 14 14:02:57 soma sshd[28272]: Changed root directory to "/var/www/vhosts/vhost1"
Dec 14 14:02:57 soma sshd[28272]: debug1: permanently_set_uid: 501/501
Dec 14 14:02:57 soma sshd[28272]: debug1: Entering interactive session for SSH2.
Dec 14 14:02:57 soma sshd[28272]: debug1: server_init_dispatch_20
Dec 14 14:02:57 soma sshd[28272]: debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
Dec 14 14:02:57 soma sshd[28272]: debug1: input_session_request
Dec 14 14:02:57 soma sshd[28272]: debug1: channel 0: new [server-session]
Dec 14 14:02:57 soma sshd[28272]: debug1: session_new: session 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_open: channel 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_open: session 0: link with channel 0
Dec 14 14:02:57 soma sshd[28272]: debug1: server_input_channel_open: confirm session
Dec 14 14:02:57 soma sshd[28272]: debug1: server_input_global_request: rtype no-more-sessions @ openssh.com want_reply 0
Dec 14 14:02:57 soma sshd[28272]: debug1: server_input_channel_req: channel 0 request env reply 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_by_channel: session 0 channel 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_input_channel_req: session 0 req env
Dec 14 14:02:57 soma sshd[28272]: debug1: server_input_channel_req: channel 0 request env reply 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_by_channel: session 0 channel 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_input_channel_req: session 0 req env
Dec 14 14:02:57 soma sshd[28272]: debug1: server_input_channel_req: channel 0 request exec reply 1
Dec 14 14:02:57 soma sshd[28272]: debug1: session_by_channel: session 0 channel 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_input_channel_req: session 0 req exec
Dec 14 14:02:57 soma sshd[28270]: debug1: session_new: session 0
Dec 14 14:02:57 soma sshd[28272]: debug1: Received SIGCHLD.
Dec 14 14:02:57 soma sshd[28272]: debug1: session_by_pid: pid 28273
Dec 14 14:02:57 soma sshd[28272]: debug1: session_exit_message: session 0 channel 0 pid 28273
Dec 14 14:02:57 soma sshd[28272]: debug1: session_exit_message: release channel 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_by_channel: session 0 channel 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_close_by_channel: channel 0 child 0
Dec 14 14:02:57 soma sshd[28272]: debug1: session_close: session 0 pid 0
Dec 14 14:02:57 soma sshd[28272]: debug1: channel 0: free: server-session, nchannels 1
Dec 14 14:02:57 soma sshd[28272]: Received disconnect from 5.187.250.144: 11: disconnected by user
Dec 14 14:02:57 soma sshd[28272]: debug1: do_cleanup
Dec 14 14:02:57 soma sshd[28270]: debug1: do_cleanup
Dec 14 14:02:57 soma sshd[28270]: debug1: PAM: cleanup
Dec 14 14:02:57 soma sshd[28270]: debug1: PAM: closing session
Dec 14 14:02:57 soma sshd[28270]: pam_unix(sshd:session): session closed for user myuser
Dec 14 14:02:57 soma sshd[28270]: debug1: PAM: deleting credentials


Minden jól működik ssh-n kivéve, hogy MC-vel nem lehet shell kapcsolattal belépni (chrootolt user):

Subsystem sftp internal-sftp -u 0000
Match group sftpgroup
X11Forwarding no
AllowTcpForwarding no
ChrootDirectory /var/www/vhosts/vhost1


Üdv!

A Raspberry-n valmelyik lábon (érintkezőn) lekérdezhető az állapota? Tehát az, hogy éppen fut, vagy suspend, vagy halt-ban van.

--
G.