- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Apple Watch Sport - ez is csak egy okosóra
- Android szakmai topik
- Huawei P30 Pro - teletalálat
- Telekom mobilszolgáltatások
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Samsung Galaxy A54 - türelemjáték
- Poco X6 Pro - ötös alá
- Érkezőben a Poco M6 4G
- Android alkalmazások - szoftver kibeszélő topik
Hirdetés
-
Free Play Days 2024 - 17. hét: Railway Empire, Prison Architect
gp Extraként a TramSim: Console Edition című játékot is kipróbálhatják az érdeklődők.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
vzozo
senior tag
Sziasztok, a nagy kérdésem az lenne, hogy mi alapján tartja "használatban" egy Linux OS a külső (USB-s) HDD-t? Konkrétan az a célom, hogy ha nincs használatban a diszk (kb. az esetek 95%-ában), akkor álljon le magától. Az enclosure van annyira okos, hogy ezt meg is teszi, pl. Raspberry-vel, Odroid N2-vel. Mindkét rendszeren valamilyen Debian klón van (raspbian, illetve armbian buster.)
Totál ugyanaz a HDD, totál ugyanazon samba beállítások mellett leáll ha nincs használva. És ez így van jól. Nincs szükség semmi hdparm varázslatra.
Ellenben most próbálkozom egy x64 alapú gépen Proxmox-szal, és habár az is debian alapú, az istenért nem állítja le a vinyót. Tudom, hogy rendszeresen pollolná a diszkeket SMART ügyileg, exceptiont beállítottam a külső lemezre. Semmi.
Egyedül ami használ, hogy ha tolok egy hdparm -B 1 / -S 36 parancsot, és akkor 3 perc után tényleg leáll a lemez, de nem maga az enclosure. A diszk nem pörög tovább, nem melegszik, halleluja - habár a SMART power on számláló továbbra is növekszik. Less than ideal.
Erre gondoltam egy olyat, hogy totál alap Linux VM-be USB passthru-n bekötöm a HDD-t, és láss csodát, bármiféle hdparm ügyködés nélkül ugyanúgy leáll a lemez, mint a fentebb említett ARM boardokkal.
Mi az amit nem veszek itt észre?
- A külső vinyó ugyanaz, ugyanazzal a fájlrendszerrel, ugyanúgy felmountolva
- smbd.conf dettó ugyanaz
- Egyedül az smbd verziók mások:Pi: Version 4.5.16-Debian
Odroid: Version 4.9.5-Debian
Proxmox hoszt: Version 4.13.13-Debian
VM: Version 4.13.14-Ubuntu -
Tiszteletem!
Végső kétségbeesésemben ide írok, hátha valaki okosabb itt, mint én. A történet annyi, hogy van egy rootolt LG Smart TV-m, amelynek sikerült kidumpolni a rootfs-ét, illetve a gyártótól rendelkezem a kernel forrásokkal, illetve egy x86_64 kompatibilis toolchainnel. A TV maga armv7 soft float.
Szeretnék appokat fordítani a TV-re, de a canadian cross compile megoldás a toolchainnel x86_64 vasról nem éppen kézenfekvő. Sokkal kényelmesebb lenne fordítani egy natív gcc-t a toolchain segítségével, majd az egészet felrakni a TV rootfs-ébe és oda chrootolva nem közvetlenül a TV-n, de egy kicsi ARM szerveren buildelni. Szóval ez az elképzelés.
A gyakorlatban nem sikerült a desktopomon futó Arch Linuxról, vagy a szerveren futó Fedoráról buildelni, egy régi ubuntu chrootot használtam, ami ráadásul 32 bites. A célnak viszont megfelel. Ami viszont érdekes, hogy nem akar lefordulni a gcc, amikor a make végigszalad az összes függőség mappáján, akkor a libgcc-nek valamiért nem adja át a gcc gyökerében lévő configure által konfigolt környezeti változókat és emiatt, mivel nem talál pár fejlécet a libgcc make, le se fordul. Nyilván kézzel lehetne korrigálni, de nem ez lenne a szép megoldás.
Erről a linkról letölthető a chroot, amiben dolgoztam: [link]
A chrootba belépve kellenek a környezeti változók a buildeléshez:
. /opt/webos-sdk-x86_64/1.0.g/environment-setup-armv7a-neon-webos-linux-gnueabi
Majd a következő sorokkal próbálok fordítani:
cd /root/gcc-build
CC="arm-webos-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=softfp --sysroot=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi" CXX="arm-webos-linux-gnueabi-g++ -march=armv7-a -mfpu=neon -mfloat-abi=softfp --sysroot=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi" ../gcc-6.2.0/configure --prefix=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi --with-mpfr=/opt/webos-sdk-x86_64/1.0.g/sysroots/armv7a-neon-webos-linux-gnueabi --host=armv7a-linux-gnueabi --target=armv7a-linux-gnueabi --build=x86_64-linux-gnu
make -j8ÉS egy kis idő után ezt a hibát dobja: [link]
Ha belenéz az ember a létrejött build mappában a libgcc config.logja tényleg mintha teljesen ignorálná a build változókat és a külső configure flageket. Nem értem mit rontok el.
Van ötlet esetleg? Nagyon jó lenne, ha sikerülne lebuildelni.
Köszi!
Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!
-
-
válasz Netszemete #31755 üzenetére
Akkor másképp: nem fut a clamav vmelyik gépeden? Másnál okozott ilyen jelenséget.
Másik lehetőség, hogy átmenetileg átállítod a DNS-t a Cloudflare-re vagy a Google-re és megnézed úgy.
https://www.coreinfinity.tech
-
Hello,
Havernak egy Süsün futó Apache-t kéne megmókolnia, hogy hajlandó legyen HSTS-t használni. Küzdünk vele egy ideje, de nem jövünk rá, mi baja. Hátha itt tudja valaki
- Apache 2.2.10 régi OpenSuse-n
- openssl ismeri a prime256v1 ECC titkosítást
- mod_headers engedélyezve, nem panaszkodik rá az ApacsDe ha nmap-pel vagy curl -s -k -D- -al megnézzük, hogy mit köp a szerver, abban nincs Strict-header. Elvileg a 2.2.6 -tól van ECC támogatás, bár egyes források 2.2.26 és 2.4 -et írnak.
Valaki fogott már olyat, hogy valamiért nem ment a Strict-Header opció Apache 2.x alatt?...bármilyen tippet szívesen fogadok...
Mutogatni való hater díszpinty
-
Ez legalább valami appliance (ami Suse alapú), amire aztán nincs repo Úgy frissül, hogy kb. újratelepíti magát. Mármint úgy frissült, mert ugye már régen unsupported, csak át kéne rugdosni az ellenőrzésen, mert nyilván évek óta cserélik le jövő hónapban.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
válasz Netszemete #31761 üzenetére
"Ez legalább valami appliance (ami Suse alapú), amire aztán nincs repo "
Mondom appliance. Tehát egy full zárt Linux, elvileg bele se nyúlkálsz (de azért bele lehet). Van rajta egy 2.2.10 Apache, ami ahhoz oda van csomagolva, az megy rajta. És ott a mod_headers, azt nem értik, miért nem működik a HSTS, ha egyszer be lehet konfigolni, konfigfile-ra nem hisztizik, error logban semmi. Ráadásul nem mai gyerek a Suse sem alatta.[ Szerkesztve ]
Mutogatni való hater díszpinty
-
-
őstag
Itt azért némileg keveredik a HSTS és az SSL/TLS történet. HSTS egy header, amit hozzáadsz a HTTPS kiszolgálóhoz és kész. Header always set Strict-Transport-Security "max-age=X; includeSubDomains"
Amennyiben jelenleg nincs HTTPS, na az gondterhesebb. Azt gondolom, hogy a TLSv1.3 már amúgy is bukta, szóval nem kell ECC-re támaszkodni, ott az oldstable RSA.
Illetve van egy olyan SO téma, ami leírja, hogy redirect esetén nem dobja a headert ez a régi verzió. Érdemes leválasztani a HTTPS és a sima HTTPt virtualhost szinten. [link]
Amennyiben minden kötél szakad le kell választani a hálózatról, és egy friss reverseproxy mögé kötni.[ Szerkesztve ]
Tegnap még működött...
-
Ha annál a cégnél ezt el lehetne normálisan intézni, szerintem már ott lenne Tehát minden egyéb megoldás kiesik, a legegyszerűbb megoldani, hogy legyen HSTS is.
@lionhearted : Másképpen keveredik
- Csak HTTPS van, a HTTP be sem volt állítva
- TLS1.2 a max., amit ismer, és 1.2 meg 1.3 használható, szóval ez pipa
- Azt néztük, hogy a prime256v1 -et ismeri, az meg ECC algoritmus, és ennyiben függene a certtől, hogy annak is támogatnia kell (azaz az issuernek, de nem igazán értettem amit találtunk rá).
Még az lehet, hogy generálnak egy új cert, ECC algoritmussal, és azzal mennie kéne (olyan találat volt, hogy a HSTS csak ECC algoritmusokkal hajlandó működni, de azok meg Apache 2.2.6 óta vannak). De pont ez a bajom, hogy a headernek szerintem meg kéne jelennie a HTTPS fejlécben... De mi okozhat egyáltalán olyat, hogy nem teszi bele? A mod_headers -nek semmi konfigja nincs.
Plusz : itthoni szerveren nekem van HSTS, és rsa 2048-as algoritmussal titkosít, a cert is olyan. Tehát nekem is meredek, hogy össze kéne függenie. (Csakhogy ez egy rendesen frissülő Debian Testing.)[ Szerkesztve ]
Mutogatni való hater díszpinty
-
luks
kezdő
Sziasztok!
Elsősorban azokat szeretném megszólítani, akik használják a newsboat cli rss feed reader-t. A napokban kezdtem elmerülni a szoftver query és filter lehetőségeiben és egy korlátba botlottam, amire szerintem nincs megoldás. Valójában nem is korlát, de felismertem, hogy idővel teljesen átláthatatlanná fog válni az urls fájlom, amiben query-ket írok, főleg akkor ha változtatni kell valamin, amiben egyik hivatkozik a másokra. Egyszerűbb, felírok egy példát az urls fájlra és elmagyarázom, hogy ott mi történik.
"query:All Security News without filtered content:tags =~ \"secnews\" and (title !~ \"docker|kubernetes|bitcoin\" and content !~ \"docker|kubernetes|bitcoin\")"
"query:Security News (docker/k8s):tags =~ \"secnews\" and (title =~ \"docker|kubernetes\" and content =~ \"docker|kubernetes\")"
"query:Security News (bitcoin):tags =~ \"secnews\" and (title =~ \"bitcoin\" or content =~ \"bitcoin\")"
https://krebsonsecurity.com/feed/ "~Krebs" secnews
https://www.schneier.com/feed/ "~Schneier" secnews
https://www.darkreading.com/rss.xml "~Dark Reading" secnews
https://feeds.feedburner.com/TheHackersNews "~THN" secnews
https://feeds.guardian.co.uk/theguardian/world/rss "~Guardian" news
Először is mi történik alul. A site rss linkjével kezdődik a sor, mellette azonnal elnevezem (
"~Krebs
), mert egyáltalán nem biztos, hogy később a default hozott nevén szeretném látni. A végén pedig megtaggelem (secnews
), hogy később tudjak hivatkozni rá, csoportosítani tudjam őket.Fent három egyszerű query-t írtam.
Kezdjük a második és a harmadikkal. Szeretném leszűrni, de csak a security orientált oldalakat vizsgálva (
tags =~ \"secnews\"
) és összegyűjteni a Docker és Kubernetes témakörben lévő cikkeketand (title =~ \"docker|kubernetes\" and content =~ \"docker|kubernetes\")
egySecurity News (docker/k8s)
nevű "mappába".A második hasonló, nem kell magyarázni. Az első query viszont érdekes, mert nem szeretnék két mappában
All Security News without filtered content
ésSecurity News (docker/k8s)
ugyanazzal a cikkel találkozni. Tehát itt mindent össze kell gyűjtenem, ami security orientált (tags =~ \"secnews\"
), de(!) ki kell szűrnöm innen minden olyan cikket, amit máshol egyéb szempontok alapján már összegyűjtöttem, ami így folytatódik:and (title !~ \"docker|kubernetes|bitcoin\" and content !~ \"docker|kubernetes|bitcoin\")
.A probléma pedig itt kezdődik. Ha szeretném kiegészíteni a Docker és a Kubernetes tartalmakat gyűjtő mappámat mondjuk egy Podman szűrővel, akkor a második query-ben két helyen kell kiegészítenem azt (
title
éscontent
szűrő), továbbá ki kell szűrnöm az első query-ből is (title
éscontent
), mert nem szeretnék egy témakört két helyen olvasni.Két dolgot látok megoldásnak, de egyiket sem gondolom megvalósíthatónak, harmadikat pedig nem látok.
1. Az urls fájlom szerintem nem tud mit kezdeni a változóval. Ráadásul a regex sem biztos, hogy tud változót kezelni. Ezt nem tudom. Ez lenne a legeslegjobb, leghibatűrőbb megoldás.
2. Ha lehetne hivatkozni egy query-ben egy másikra, már az megkönnyítené a későbbi változtatás módosításokat az urls fájlban. Gondolok itt arra, hogy ha a második query-ben szűrök konténerizáció témakörben, akkor ne kelljen felsorolni az első query-ben újra, hogy de ezeket viszont itt nem szeretném, egyszerűen csak ne jelenítsd meg azokat, amit a második query-ben meg szeretném, hogy jeleníts. (Itt olvashatóak, hogy milyen operátorok és attribútumokra lehet hivatkozni.)Ez most még nem okoz jelentősebb problémát és a fentiek is csak egy hasra csapott példasor, de már látom, hogy idővel teljesen átláthatatlanná válhat a saját konfigurációm és a hozzáadok, elveszek szerkesztések is nagyban növelni fogják az emberi hiba lehetőségét.
Aki végigolvasott, köszönöm!
[ Szerkesztve ]
-
őstag
Így látatlanban nehéz mit mondani, hacsak nem valami bug az adott változatban, akkor nincs összefüggés a kulcs algoritmusa és a fejlécek között.
Hogy miért nem teszi bele, ez is lehet sokféle. Nem kizárt, hogy rossz ágon nézi, vagy van egy feltétel, ami mégse teljesül, ilyesmi. Érdemes lehet egy foo.bar headerst betenni debugnak.Tegnap még működött...
-
válasz lionhearted #31768 üzenetére
Az hogyan...?
Amúgy... Hm, az IfModule-t elírhatták, de... Azért csak nem.
Még olyat gondolok, hogy nem a default virtualhoston fut a cucc, de az meredek lenne...[ Szerkesztve ]
Mutogatni való hater díszpinty
-
őstag
-
válasz lionhearted #31770 üzenetére
Én is, mert mindenféle balf*ságot elkövettem már éles rendszeren De ez a "bürokratikus probléma IT megoldása" sok volt, pár éve otthagytam azt a céget
Mutogatni való hater díszpinty
-
vicze
félisten
-
-
válasz Netszemete #31774 üzenetére
Jaja. Elvileg az always-t állították be. (Nekem ott az volt az új, hogy van nem always )
Mutogatni való hater díszpinty
-
CPT.Pirk
Jómunkásember
Van egy gép Debiannal. Rajta SSH. Annyit szeretnék elérni, hogy csak azokat a felhasználókat engedje be, akiknek a publikus kulcsa benne van a
/home/felhasználóm/.ssh/authorized_keys
fájlban.Ezek lettek módosítva van az
/etc/ssh/sshd_config
fájlban:PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
Aztán
systemctl restart ssh
paranccsal élesítem.Ez így viszont nem jó. Ha be akarok lépni másik gépről, akkor kéri a passphrase-t, aztán rögtön utána permission denied (Publickey)-t kapok.
Ha a
PasswordAuthentication
értéke yes, akkor belépéskor kéri a passphrase-t, majd kéri a userem jelszavát és be is enged. No de akkor is beenged, ha kikommentezem a gépem ssh kulcsát az auth. fájlban! Olyankor nem kérdezi a passphrase-t, csak a felhasználóm jelszavát és az elég neki a beengedéshez...Mit kellene máshogy csinálnom, hogy ne engedjen be olyat, akinek nincs ott az ssh kulcsa a gépen? Akkor se, ha egyébként tudja a jelszót a userhez. Már vagy 10 leírást végigolvasva sem jöttem rá a megoldásra.
[ Szerkesztve ]
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
CPT.Pirk
Jómunkásember
A key fájl az 664, és a tulajdonosa a userem. Ez szerintem oké.
Az egészet nem másoltam be, a lényeg szerintem innen van a -v -vel futtatáskor:
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\Borisz/.ssh/id_rsa RSA SHA256:szPorBR6Y3azDvPx3qlkfoUKJWOCqMu0pDen/EALbVM
debug1: Server accepts key: C:\\Users\\Borisz/.ssh/id_rsa RSA SHA256:szPorBR6Y3azDvPx3qlkfoUKJWOCqMu0pDen/EALbVM
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Enter passphrase for key 'C:\Users\Borisz/.ssh/id_rsa':
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_xmss
debug1: No more authentication methods to try.
borisz@...: Permission denied (publickey).
Aztán a -vvv -vel futtatva ugyanez így néz ki:
debug3: sign_and_send_pubkey: signing using rsa-sha2-512
debug3: failed to open file:C:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Enter passphrase for key 'C:\Users\Borisz/.ssh/id_rsa':
debug2: no passphrase given, try next key
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_dsa
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_dsa: No such file or directory
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ecdsa
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ed25519
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_xmss
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
borisz@...: Permission denied (publickey).
Vagyis ha jól értem, ezt nem lehet üres passphrase-el használni?
[ Szerkesztve ]
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
CPT.Pirk
Jómunkásember
Mikor kérte a passphrase-t, akkor entert ütöttem. Vagyis elvileg nincs passphrase. Ugyanezen a gépen van git szerverem a git felhasználó alatt, ott ez a pubkey működik.
Nekem ez gyanús:
can't open /dev/tty: No such file or directory
Hogy ezt a Windowsos gép cmd-je adja vissza. Mert hát ez Linuxos fájlrendszerben keres valamit Windows alatt. Vagy nem tudom.Netszemete:
A useremnek van jelszava.[ Szerkesztve ]
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
CPT.Pirk
Jómunkásember
Generáltam új fájlt magamnak, benne passphrase-el. Most fasza, és csak akkor enged be, ha tényleg jó a kulcsom.
Nem tudom mi lehetett a baj az előzővel, ha a GIT-et tudtam vele használni ezen a gépen. Mindegy, csinálok mindenkinek új ssh fájlt, passphrase-el aztán akkor menni fog.
[ Szerkesztve ]
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
nagyúr
-
CPT.Pirk
Jómunkásember
Kipróbáltam otthonról, Linuxos gépemen ugyanúgy passphrase nélkül generáltam az ssh kulcsot pár hónapja. Viszont innen minden további nélkül beengedett vele. Én betudom valami Wines bugnak a dolgot...
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
CPT.Pirk
Jómunkásember
Nem, az a sima céges gépem, amin W10 fut. Nyitottam rajta egy cmd-t és onnan a Winben alapból meglévő ssh progival akartam belépni a Linuxos szerver gépre.
Netszemete:
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
őstag
válasz Netszemete #31776 üzenetére
Még van pár public DNS, cloudflare (1.1.1.1) felül is.
Nagyobbak:
* OpenDNS (208.67.222.222)
* Quad9 (9.9.9.9)
* Comodo (8.26.56.26)Ezenfelül is van számos, elég rákeresni a "public DNS" kifejezésre.
Tegnap még működött...
-
sonar
addikt
Sziasztok,
A következő a problémám.
Adott egy 20.04-es ubuntu meg egy x710 (SFP-s változat)
10G-s DAC kábelekkel szépen megy, viszont 1G-n SFP modullal sehogy se. Állandóan No-Carrier.
FW-t megfrissitettem, i40e driverből is felraktam az utolsót. Ugyanez a konfig Win10-en működik. (1G-vel és 10G-vel is)
Most kicsit tanácstalan vagyok. Van vkinek vmi tippje?A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
CPT.Pirk
Jómunkásember
Szeretném biztonságosabbá tenni az úgymond szerver, Lubuntu 20.04 gépemen az SVN elérést. A gépre SSH-n keresztül be lehet menni és GIT szerver is fut rajta, de mind a kettő csak SSH kulccsal működik, szóval ezek rendben vannak.
Az svn viszont nem. Azt jelenleg egy apache webszerver szolgálja ki, amit így http kapcsolaton keresztül lehet elérni, azon belül meg név és jelszó van csak mint biztonság...
Amit ezen a téren találtam, az az ssh+svn elérés, az svnserve programon keresztül. A Debianos leírás alapján megcsináltam a system-s beállítást, bár nem külön svn felhasználó alá, de ez most szerintem mindegy, azt majd talán később megcsinálom ha már egyáltalán működik.
A Daemon konfigjánál viszont elakadok. A példában nem használnak ssh-t, se a defaulttól eltérő portot.
# svnserve options DAEMON_ARGS="--daemon --pid-file /run/svnserve/svnserve.pid --root /srv/svn/repos --log-file /var/log/svnserve/svnserve.log"
Nem tunneling verzióban a daemon elindult. Viszont nézve az svnserve leírását, nem világos, hogy mit kell benne megadnom a tunneling használatához.
Szerintem a
--daemon
helyére kell egy-t
, hogy tunneling, ez az ssh. Viszont utána kell-e--tunnel-user akármi
,próbáltam többféle verzióban megadni de egyikkel se indult el a daemon. Az sem világos, hogy az "akármi" megadása milyen formában szükséges. Egyszerűen csak oda kellene írnom úgy és annyiszor, ahány ember ssh kulcsát felviszem a gépre?
Szóval ilyen--tunnel-user bela
--tunnel-user jozsi
--tunnel-user pista
módon kell ezt megadni, ha ennek a 3 embernek felvittem a publikus kulcsát a gépre?Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
Új hozzászólás Aktív témák
- Microsoft licencek a KIVÉTELES ÁRAK - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig
- Windows 10/11 Home/Pro , Office OEM/Retail kulcsok
- Steam, Windows, Origin kulcsok, előfizetések közvetlenül a kiadótól, a LEGJOBB ÁRON!
- AKCIÓ! - STEAM kulcsok /Anuchard, Aragami, Children of Morta, stb. - 2024.04.17.