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!

Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!

ClamAV?

https://www.coreinfinity.tech

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 Apacs

De 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

Szoktak lenni non-official repok ahol van újabb apache. Ha enterprise suse néha ahhoz is.

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

"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

Hdparm nem tud ebben segíteni? Asszem valahogyan lehet zaklatni a winyókat, hogy azt csinálják, amit akarsz tőlük.

Mutogatni való hater díszpinty

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

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ő cikkeket and (title =~ \"docker|kubernetes\" and content =~ \"docker|kubernetes\") egy Security 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 és Security 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 és content szűrő), továbbá ki kell szűrnöm az első query-ből is (title és content), 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 ]

Í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...

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

É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

"Megértem, de a jövő hónapban migrálunk 2éve, problémára ez a tartós megoldás,"
Management / compliance droidokon kívül mindenki tudja. A tartós megoldás az egész kotla cseréje lenne. Többit ld. #31771.

Mutogatni való hater díszpinty

Jaja. Elvileg az always-t állították be. (Nekem ott az volt az új, hogy van nem always )

Mutogatni való hater díszpinty

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)

mutass egy ssh -v kimenetet

ezenkivul:
- a helyi ssh privát kulcsnak 0600-as permissionnel kell rendelkeznie
- authorized_keys-nek 0644-el es az usernek kell birtokolnia

[ Szerkesztve ]

while (!sleep) sheep++;

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)

> Vagyis ha jól értem, ezt nem lehet üres passphrase-el használni?

de, annak mennie kell -- ránézésre ennek a keynek _van_ beállítva passphrase, csak nem írod be

while (!sleep) sheep++;

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)

biztos vagy abban, hogy nincs a kulcson passphrase?
PasswordAuthentication no elég kell legyen, a kulcsoddal van probléma.

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)

Ha pp-el rendelkező ssh kulcsot használsz es entert utsz, az az jelzi az ssh-nak, hogy nem akarod használni a kulcsot.

while (!sleep) sheep++;

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)

Nincs ilyen Windowsos bug.

while (!sleep) sheep++;

Akkor miért kaptam vissza /dev/tty-ra mutató hibát a logban Windows alatt?

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Haha, figy, ez Cygwin? Meg Windows 10-re upgradelt PC?

[ Szerkesztve ]

while (!sleep) sheep++;

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)

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!

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)