Debian GNU/Linux

Debian Squeeze - rajta samba apache2 squirrelmail+courier IMAP és persze exim4. Alapvetően három felhasználóval - (én a nejem és a "más" nejem).
Kellene egy "rendszer idegen" account.
Alapvetően scp és html_public hozzáférést szeretnék/kellene biztosítanom. Viszont (ha jól emlékszem) ahhoz hogy az scp működjön, kell shell hozzáférés. Ráadásul, globálisan a többi felhasználó mappáit is lehet "böngészni".
Le lehet tiltani az ssh shell hozzáférést és a korlátozni, hogy csak a saját könyvtárában mozoghasson úgy, hogy a globális beállításokat ne módosítsam?
Eddig nem találtam ilyen korlátozási lehetőségeket per user.

Több megoldás is létezik! Mindenkinek köszönöm és ha valaki tud valamit még akkor írjon!

Sziasztok!

Egy frissen telepített wheezy-ben kisérletezek az lxc-vel.
Mindent a http://wiki.debian.org/LXC szerint csináltam. Sajnos nincs console amikor be akarok lépni
a virtuális gépbe. A következő parancsokat adtam ki:

lxc-create -n lxc-debian -t debian
lxc-start -d -n lxc-debian
lxc-console -n lxc-debian

Később módosítottam a config file-t, majd chrottal raktam rá openssh servert.
Így ssh-val most be tudok lépni. De sajnos console most sincs.

A config file mostani tartalma:
# /var/lib/lxc/lxc-debian/config

## Container
lxc.utsname = lxc-debian
lxc.rootfs = /var/lib/lxc/lxc-debian/rootfs
lxc.arch = x86_64
#lxc.console = /var/log/lxc/lxc-debian.console
lxc.tty = 6
lxc.pts = 1024

## Capabilities
lxc.cap.drop = mac_admin
lxc.cap.drop = mac_override
lxc.cap.drop = sys_admin
lxc.cap.drop = sys_module
## Devices
# Allow all devices
#lxc.cgroup.devices.allow = a
# Deny all devices
lxc.cgroup.devices.deny = a
# Allow to mknod all devices (but not using them)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m

# /dev/console
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/fuse
lxc.cgroup.devices.allow = c 10:229 rwm
# /dev/null
lxc.cgroup.devices.allow = c 1:3 rwm
# /dev/ptmx
lxc.cgroup.devices.allow = c 5:2 rwm
# /dev/pts/*
lxc.cgroup.devices.allow = c 136:* rwm
# /dev/random
lxc.cgroup.devices.allow = c 1:8 rwm
# /dev/rtc
lxc.cgroup.devices.allow = c 254:0 rwm
# /dev/tty
lxc.cgroup.devices.allow = c 5:0 rwm
# /dev/urandom
lxc.cgroup.devices.allow = c 1:9 rwm
# /dev/zero
lxc.cgroup.devices.allow = c 1:5 rwm

## Limits
#lxc.cgroup.cpu.shares = 1024
#lxc.cgroup.cpuset.cpus = 0
#lxc.cgroup.memory.limit_in_bytes = 256M
#lxc.cgroup.memory.memsw.limit_in_bytes = 1G

## Filesystem
lxc.mount.entry = proc /var/lib/lxc/lxc-debian/rootfs/proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry = sysfs /var/lib/lxc/lxc-debian/rootfs/sys sysfs defaults,ro 0 0
#lxc.mount.entry = /srv/lxc-debian /var/lib/lxc/lxc-debian/rootfs/srv/lxc-debian none defaults,bind 0 0
# Container with network virtualized using a pre-configured bridge named br0 and
# veth pair virtual network devices
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 4a:49:43:49:79:bf
lxc.network.ipv4 = 10.2.3.5/24
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597

Már kiolvastam a teljes internetet és nem találok megoldást. :(
Tudna valaki segíteni?

Egy kis jelszóval "védett" html készletet kell migrálnom. Az eredeti gépen Debian Etch iso8859-2 hu_HU az új UTF8 us_EN az alap locale. A .htaccess fájlt konvertáltam utf8 -be (iconv) és létrehoztam a rendszernek megfelelő password fájlt, de nem működik :(
Létrehoztam új felhasználót, módosítottam a .htaccess fájlt, majd létrehoztam egy új jelszófájlt (/usr/share/apache2/passwd/passwords) akkor sem akar működni. Az előző verzióban elkövettem azt a baklövést, hogy ékezetes betűt használtam a felhasználói névben.
Egyébként a "Basic Authentication" infrastruktúra működik:
Ha a régi rendszerből átmásolom a .htaccess és password fájlokat, rendben működik - mint a másik gépen, mintha mi sem történt volna.
Azonban ezt nem tartom túl egészségesnek - ha módosítanom kell, vagy új felhasználó/jelszó párost kell előállítanom akkor nem tudom mi lesz :(
XP -ről próbélgattam, firefox böngészővel, állítgattam az alap kódlapot (érdekes, a hibás azonosítás után bezárom az azonosító ablakot - Esc - és a nézetben, alapból az iso8859-1 beállítás látszik, ha átállítom uft8 -ra újra feldobja az azonosító mezőt, de akkor sem fogadja el a szerver.
Valami ötlet?

Az apache2 a /var/log/apache2/error.log -ba a következő hiba sorokat generálja:

[quota]
[Sat Jan 19 12:11:47 2013] [error] [client 192.168.1.80] 2013.01.19 12:14:49 , referer: http://192.168.1.250/~tovis/cgi-bin/bubu.cgi
[/quota]

A bubu.cgi létezik, és minden mintha rendben lenne vele - azaz a kliensen megjelenik és működik ... Ráadásul ez egy "önfrissítő" script azaz 5 sec -ént frissíti magát - így a hibaüzenetek is ilyen sűrűséggel érkeznek.

Mi lehet ez a hiba? Miért panaszkodik az apache2?

Adva van egy régi Etch (Debian 4.0) gép, iso8859-2 azaz HU_hu locale -val.
rsync -elni akartam volna egy Squeeze -re UTF8 en_US.UTF-8 lacale.
A következő hibát dobja:

protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(173) [Receiver=3.0.7]

Nem tudom mit tudok ezzel tenni?
Megpróbálom daemon módba tenni a remote gépen az rsnc -et.

Van/volt egy gép Debian Etch(!) azaz 4.x - az lapalap szépen kezd kirohadni alóla. Új alaplap - új Debian - Squeeze.
A szerkezet egyik feladata, a MySQL - régi 5.0.51a-3 backport volt akkor - az új a Squeeze repóból, az 5.1.66-0+squeeze1.
A régi verzióban így mentettem ki az adatbázist:
mysqldump --password="jelszó" --all-datzabases > mysql-all-"dátum".sql
Illetve rendelkezésre áll a konkrét adatbázis:
mysqldump --pasword="jelszó" --databases db > db-"dátum".sql
A "db" adatbázist, egy XP -n futó program használja ODBC 3.51 interfészen keresztül.
A migrálásnál már az problémát okozott hogy a dump -ban a db nagybetűkkel volt írva, mire a mysql < db-"dátum".sql parancsnál kijelentette hogy nem ismeri!? Némi küzdelem árán (azért már több száz mega) átírtam kisbetűre - akkor megette. phpmyadmin alól láttam, hogy ott van. Kicsit masszíroznom kellet a hozzáférő felhasználók listáját, de végül az antik ODBC is tudott kapcsolódni és látta az adatbázist - furcsán lassan kezelte a "teszt" parancsot is. Elindítottam a programot az új szerverrel de SQL hibával leállt - a program szerencsére naplóz, egy az egyben az ODBC üzeneteit továbbítja, és ott azt mondta hogy a AEvt.acar tábla nem létezik :(
Valóban, a pphpmyadmin -ban látszik, hogy a táblát "aevt" -nek hívja, vagyis megint kisbetű/nagybetű gond van.
Tudja valaki mit kellene még bekonfigurálni?

Nem igen értem, biztos vagyok benne, hogy ilyen szintű inkompatibilitás nem lehet a MySQL -ben, úgy hogy 5.0.x - 5.1.x
Tény hogy az előző rendszer HU_hu azaz iso8859-2 volt, most a Squeeze -t en_utf8 -ra tettem, de a tábla definíciókban mindenütt benne van, hogy "default charset latin1" (mondjuk ezt sem igazán értem - latin2 kéne - de működött).

Hello.

A cegtol hoztam haza egy pendriveot amin bootolhato linux volt.

Beirtam cfdisk, ami a default /dev/sda - t huzta be es szepen leszedtem minden filerendszert, gondolvan h jol hivatkozva inditottam el a cfdisket.

A filerendszer es tartalma ott van, erintetlen de a descriptor resz total legyalulva.

Esetleg vmi tool-al ujra lehet scannelni es helyreallitani?

Elore is koszonom a valaszokat.

Sziasztok, van 1 csak Adobeval olvasható PDF-em, ha .ps-be nyomtatok belőle, akkor is csak azt a szabvány előnézeti képet exportálja belőle az Adobe Reader, hogy Please wait... if this message is not eventually replaced by proper document, your PDF viewer may not be able to display this type of document.

Szóval tényleg olyan a dokumentum, hogy semmi nem támogatja, még azt sem, hogy az egyes oldalakról egy képsort kapjak fájlokba. De nekem OCR-eznem kell ráadásul egy pici képernyőn, szerintetek hogy álljak neki?

Használok egy olyan szervert, aminek úgy tűnik nincs mások által hitelesített certificate -ja.
A fetchmail folyamatosan hibákat dobál, most éppen:

fetchmail: starting fetchmail 6.3.18 daemon
fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: This means that the root signing certificate (issued for /O=\xC3\x81rk\xC3\xA1d M\xC5\xB1ki Rt./C=HU/ST=Hungary/L=Budapest/CN=bubuka.hu) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
fetchmail: Server certificate verification error: unable to verify the first certificate
fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)

Ez most azután, hogy lehúztam a certificate -et
openssl s_client -connect szerverke:995 -showcerts
az itt kapott infóból kiszereltem a certificate, és bemásoltam a /user/share/ca_certificates/ alá a szerverke/szerverke.pop.pem néven, majd az /etc/ssl/certs/ könyvtárba készítettem egy symlinket és végül c_rehash.
Viszont a hitelesítő az ugyanez a certificate.
Meg lehet egyáltalán oldani?
Megkegyzés: ettől persze a leveleket lehúzza, de unom a sok fölösleges zörgést a naplóba.

Hulye cim, tudom. Jo ideje mukodott az s2disk, debian testingen. Most meghalta magat, 70%-nal baja van. Serult a swap particio vagy mittomen, nem is erdekel. A nagy gondom az, hogy nem tudom rabirni a grubot, hoyg hagyja a nyavalyavaba a visszaallitast, induljon normalisan.

Valami otlet?
64 bites Debian testing, GRUB2, kernel 3.2.0-4