Linux-kysymyksiä & yleistä keskustelua Linuxista

"build-essential" joutui asentamaan ensin, ei toiminut compiler muuten.

En saanut tuota "RHash can use optimized algorithms of MD5, SHA1, SHA2 from the OpenSSL library. To link OpenSSL at run-time (preffered way)" hommaa toimimaan. Tulee "Error: OpenSSL library not found" viestiä kun ajaa komennon ./configure --enable-openssl-runtime && make. Config.logissa oli joku "use --enable-openssl=runtime instead of --enable-openssl-runtime" varoitus ja kokeilin tuota suositeltua parametriä myös mutta ei toimi.

Kokeilin sitten vaan ./configure && make ja se näytti toimivan ihan ok. Sen jälkeen kokeilin ekaksi ilman sudoa make install mutta se antoi "cannot create regular file '/usr/local/bin/rhash': Permission denied" virheen. Sudolla näytti toimivan homma, ei ainakaan virheitä näkynyt.

Mutta sitten kun yrittää ajaa tuota uutta softaa niin tulee: "fatal error: incompatible librhash version is loaded: 1.3.9". EDIT: Liittyykö tämä nyt siihen "Building an OS native package" osioon tuolla install ohjeissa? En oikein tajua mitä komentoja pitäisi käyttää tuolta osiosta.. etten rävellä vaan järjestelmää pahasti sotkuun..

Taisi olla vähän liian edistynyttä touhuilua tämä koko homma mulle? :)
En jaksanu tarkemmin tutkia, mutta kannattaa aina GitHubista tsekata Issuet:

Ehkäpä tuolta löytyy ratkaisu, ehkä ei...
 
Solmuun meni jotenkin. Onnistuin kyllä asentamaan "--enable-static" parametrillä ja softaa sai ajettua mutta se toimi jotenkin oudosti joten päätin lopettaa kikkailun ja palata lähtöruutuun. Yritin "make uninstall" ja näytti lähteneen järjestelmästä, sitten vaan ubuntu/mint reposta vanha asennukseen mutta sen jälkeen ei rhash komento toiminut kuitenkaan "No such file or directory" samassa terminaali-ikkunassa, piti avata uusi terminaali-ikkuna että komento toimi.. eipä ole tullut tuollaista ennen vastaan. Ei olisi pitänyt lähteä säätämään.. pitää ehkä varmuudeksi palauttaa snapshot ennen säätöjä.
 
Löytyi valmiina tällaiset (Mint 20.2 Cinnamon):

Koodi:
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.

GNU Make 4.2.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2016 Free Software Foundation, Inc.
Onko liian vanhat vai onko sillä mitään väliä?
Tuo "RHash can use optimized algorithms of MD5, SHA1, SHA2 from the OpenSSL library. To link OpenSSL at run-time (preffered way), configure RHash as ./configure --enable-openssl-runtime" varmaan olisi järkevä enabloida. OpenSSL löytyy tällainen valmiina: "OpenSSL 1.1.1f 31 Mar 2020" järjestelmästä, eikös se riitä? Jos vain ei ole liian vanha versio?
Jos kehittäjä ei asennusohjeissaan mainitse riippuvuuksien versioista mitään, niin aika mahdotonta on tietää, mikä on liian vanha ja mikä ei. Mutta hyvä nyrkkisääntö on varmaan, että jos distro on vain pari vuotta vanha (kuten Mint 20.2), niin kaiken pitäisi toimia, ellei muuta sanota.


"build-essential" joutui asentamaan ensin, ei toiminut compiler muuten.
Tää on aika jännä, että vaikka gcc ja make oli jo asennettuna, niin silti ei toiminut. Ilmeisesti on mahdollista, että C-standardikirjaston osa "libc6-dev" puuttuu, vaikka C-kääntäjä gcc on asennettuna, ja tuo "build-essential" sitten varmistaa sen, että "libc6-dev" asentuu myös.

Solmuun meni jotenkin. Onnistuin kyllä asentamaan "--enable-static" parametrillä ja softaa sai ajettua mutta se toimi jotenkin oudosti joten päätin lopettaa kikkailun ja palata lähtöruutuun. Yritin "make uninstall" ja näytti lähteneen järjestelmästä, sitten vaan ubuntu/mint reposta vanha asennukseen mutta sen jälkeen ei rhash komento toiminut kuitenkaan "No such file or directory" samassa terminaali-ikkunassa, piti avata uusi terminaali-ikkuna että komento toimi.. eipä ole tullut tuollaista ennen vastaan. Ei olisi pitänyt lähteä säätämään.. pitää ehkä varmuudeksi palauttaa snapshot ennen säätöjä.
Meinasin jo aiemmin varoittaa, että jos alkuperäinen kysymys on luokkaa "pitääkö asentaa joku compiler", niin on aika epätodennäköistä, että seuraava kommentti on "kiitos, sain asennettua, kaikki toimii". Enkä tarkoita sitä, että vika olisi käyttäjässä, vaan sitä, että githubista löytyvät asennusohjeet on lähes poikkeuksetta sellaista kuraa, että aika paljon joutuu soveltamaan ennen kuin kaiken saa toimimaan. Hyvä, jos on olemassa joku "undo-suunnitelma", jolla voi tarvittaessa kumota epäonnistuneet asennusyritykset.
 
githubista löytyvät asennusohjeet on lähes poikkeuksetta sellaista kuraa, että aika paljon joutuu soveltamaan ennen kuin kaiken saa toimimaan
Siltä se itsestäkin tuntui kun noita rhashin ohjeita katselin. :)

Hyvä, jos on olemassa joku "undo-suunnitelma", jolla voi tarvittaessa kumota epäonnistuneet asennusyritykset.
Aina... tai ainakin yrittää muistaa aina. ;) Palautin Timeshiftin snapshotin ja nyt pitäisi olla alles gut taas.
 
En ole varma, mutta en oikein osannut kokeillä muutakaan? Joskus löysin artikkelin, mitä bitrate/samplerate asetusta suositellaan käytettävän windowsissa ja vastaus oli korkein mahdollinen. Oletin vain että sama pätee tässä tilanteessa?
Tähän asti tämä setup on ollut todella plug & play. Koska en tiedä aiheesta oikein mitään, olen hieman eksyksissä.

EDIT: Löysin Head-fi foorumeilta keskustelun tästä samasta aiheesta! Yleinen mielipide oli että windowsilla äänenlaatu on parempi virallisen ajurituen takia? Muutama henkilö oli tätä vastaan, mutta eivät tarjonneet mitään ohjeita.
Helpottaisi paljon asiaa, jos osaisit kuvailla, mikä siinä äänenlaadussa on pielessä. Näytteenoton nostaminen yli 44,1 kHz:n parantaa noita yli 22 kHz äänien kuuluvuutta. Ihmisen kuuloalue on 20-20000 Hz, ihan referenssinä. Korkeasta resoluutiosta prosessoinnissa on apua lähinnä, jos teet jotain DSP-muunnoksia.
 
en jälkeen ei rhash komento toiminut kuitenkaan "No such file or directory" samassa terminaali-ikkunassa, piti avata uusi terminaali-ikkuna että komento toimi.

Jos käytössä on Bash niin tämä lienee Bashin cachetusominaisuuden kepposia, eli komentojen (täydet) polut talletetaan ko. shellisession ajaksi. Kun ajaa PATHista löytyvän komennon pelkällä komennon nimellä, tallennetaan absoluuttinen polku kyseiselle komennolle. Nyt vaikka executable siirtyisi toiseen hakemistoon, yrittää Bash käyttää sitä tuolla aiemmin tallennetulla polulla.

Cachen kanssa voi värkätä hash komennolla. Esim. hash -t rhash näyttää mikä polku rhash komennolle on tallennettuna. hash -d rhash poistaa tallennetun polun jolloin seuraavalla ajokerralla etsitään taas PATHista ja ajetaan sieltä mistä se löytyy (ja laitetaan taas polku jemmaan).
 
@TenderBeef Kokeileppa näin:

Bash:
sudo -i

apt update
apt install build-essential fakeroot dpkg-dev debhelper-compat

mkdir rhash
cd rhash
wget https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/rhash/1.4.1-2/rhash_1.4.1-2.dsc https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/rhash/1.4.1-2/rhash_1.4.1.orig.tar.gz https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/rhash/1.4.1-2/rhash_1.4.1.orig.tar.gz.asc https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/rhash/1.4.1-2/rhash_1.4.1-2.debian.tar.xz

dpkg-source -x rhash_1.4.1-2.dsc

cd rhash-1.4.1/
dpkg-buildpackage -rfakeroot -b

cd ..

dpkg -i rhash_1.4.1-2_amd64.deb

# Ja dev paketin asennus onnistuu näin:
dpkg -i librhash-dev_1.4.1-2_amd64.deb

En tätä nyt Linux Mintissä testannut, mutta teoriatasolla saat näin minkä tahansa source paketin / .dsc tiedoston buildattua omaan distroosi sopivaksi deb paketiksi.
 
Oli sähköt poikki niin kauan, että palvelimen (Ubuntu server 20.04) UPSista loppui akku. Selasin syslogia, ja sen mukaan sammutus alkoi UPSin alhaisen akun varauksen takia. Mistä tiedän menikö sammutus loppuun asti niinkuin pitikin, vai loppuiko akku kesken? Sammutuksen aloituksen jälkeen on pitkä lista rivejä eri palvelujen pysäytyksistä, joista viimeisenä "Stopping Systems Management SNMP..." Sen jälkeen alkavat käynnistykseen liittyvät rivit. Pitäisikö lokissa siis olla jokin selvä ilmoitus siitä, että kone sammuu?
 
Varmaan niiden stopping -rivien joukossa on jotakin sellaisia rivejä joissa sammutetaan ja irroitetaan massamuistit, sellaiset rivit yleensä ovat viimeisten lokirivien joukossa. Itselläni näkyy viimeisessä sammutuksessa "Deactivating block devices" ja sen jälkeen vielä sammuu verkkokortti ja siitä eteenpäin lokilla näkyykin jo seuraavaa boottia. Yleensä kesken jääneessä sammutuksessa lokiin on tullut jotain puuroa muuaman merkin verran ihan viimeiseksi.

Itseasiassa kävinkin kurkkaamassa mun leikkiserverin lokiakin ja siinä näkyy melkein viimeisten joukossa tuo Systems Management SNMP eli todennäköisesti on sammunut oikein.
 
Varmaan niiden stopping -rivien joukossa on jotakin sellaisia rivejä joissa sammutetaan ja irroitetaan massamuistit, sellaiset rivit yleensä ovat viimeisten lokirivien joukossa. Itselläni näkyy viimeisessä sammutuksessa "Deactivating block devices" ja sen jälkeen vielä sammuu verkkokortti ja siitä eteenpäin lokilla näkyykin jo seuraavaa boottia. Yleensä kesken jääneessä sammutuksessa lokiin on tullut jotain puuroa muuaman merkin verran ihan viimeiseksi.

Itseasiassa kävinkin kurkkaamassa mun leikkiserverin lokiakin ja siinä näkyy melkein viimeisten joukossa tuo Systems Management SNMP eli todennäköisesti on sammunut oikein.

Käytännössä kun database serveri ja muut mahdollisesti aktiivisesti levylle kirjoittavat palvelut on saatu alas, niin ei ole enää niin väliä. Tosin innodb jos on ajossa niin se ei mene hajalle vaikka virrat katoaisi kesken kirjoituksen.
Kaikki on käytännössä kehittyny niin paljon että on tosi vaikea saada filesysteemiä esim hajalle sähkökatkon takia, tai databasea. Joskushan tää oli ihan realismia, jos virrat lähti kesken kaiken niin sai jännittää että nouseeko ylös.
 
Käytännössä kun database serveri ja muut mahdollisesti aktiivisesti levylle kirjoittavat palvelut on saatu alas, niin ei ole enää niin väliä. Tosin innodb jos on ajossa niin se ei mene hajalle vaikka virrat katoaisi kesken kirjoituksen.
Kaikki on käytännössä kehittyny niin paljon että on tosi vaikea saada filesysteemiä esim hajalle sähkökatkon takia, tai databasea. Joskushan tää oli ihan realismia, jos virrat lähti kesken kaiken niin sai jännittää että nouseeko ylös.
Juu, nykyään tiedostojärjestelmät ovat yllättävän vikasietoisia ja tietenkin jos jotain serveriä tms pyörittää niin suosiolla kannattaa sellaiseen valitakin sellainen fs joka sietää sähkökatkon kaltaisia ylläreitä edes kohtuullisesti. Joskus ext2-aikakautena joku sähkökatko saattoikin sotkea järjestelmän kunnolla mutta eipä näillä nykyaikaisilla tiedostojärjestelmillä enää tarvitse paljoa pelätä.
 
Mikähän hitto on, kun juuri asennettussa DietPissa toimii SSH kirjautuminen ihan OK ethernetissä, mutta kun WLANin yli yritän kirjautua (ethernet-kaapeli irroitettu, DietPi buutattu), antaa kyllä salasanan syöttö -promptin, mutta herjaa väärää salasanaa. Salasana siis toimi hienosti ethernetin yli?
 
Mikähän hitto on, kun juuri asennettussa DietPissa toimii SSH kirjautuminen ihan OK ethernetissä, mutta kun WLANin yli yritän kirjautua (ethernet-kaapeli irroitettu, DietPi buutattu), antaa kyllä salasanan syöttö -promptin, mutta herjaa väärää salasanaa. Salasana siis toimi hienosti ethernetin yli?
Äkkiseltään voisi arvella, että sshd sallii yhteydet jostain syystä ainoastaan siitä wlan interfacesta, seuraavien komentojen outputit voisi ehkä vähän valaista tilannetta:
Bash:
ifconfig

grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

netstat -tulpn | grep :22

Toki sitten ihan yhdistäessä voisi käyttää:
Bash:
ssh -v ip.osoite
niin voisi saada vähän enemmän irti, että miksi ei toimi.
 
Mikähän hitto on, kun juuri asennettussa DietPissa toimii SSH kirjautuminen ihan OK ethernetissä, mutta kun WLANin yli yritän kirjautua (ethernet-kaapeli irroitettu, DietPi buutattu), antaa kyllä salasanan syöttö -promptin, mutta herjaa väärää salasanaa. Salasana siis toimi hienosti ethernetin yli?
Tää on ehkä liian simppeli vastaus, mutta onhan varmasti käyttäjänimi WLANin yli kokeiltaessa oikea? Varsinkin jos on tottunut käyttämään käyttäjänimetöntä ssh-komentoa ympäristössä, jossa melkein kaikissa päätelaitteissa on sama käyttäjänimi, niin sitten kun jossain päätelaitteessa onkin eri nimi, niin se käyttäjänimetön komento ei enää toimikaan (kysyy kyllä salasanaa, muttei hyväksy mitään).
 
Mikähän hitto on, kun juuri asennettussa DietPissa toimii SSH kirjautuminen ihan OK ethernetissä, mutta kun WLANin yli yritän kirjautua (ethernet-kaapeli irroitettu, DietPi buutattu), antaa kyllä salasanan syöttö -promptin, mutta herjaa väärää salasanaa. Salasana siis toimi hienosti ethernetin yli?

sshd antaa yhteyttä yrittävälle aina salasanan syöttö-promptin, vaikka yhteydet olisikin sallittu ainoastaan SSH-avainautentikoinnilla ja/tai /etc/ssh/sshd_config -tiedostossa olisi määritys että tiettyä käyttäjätunnusta tai tietystä lähtö-IP-osoitelohkosta tulevia yhteyksiä ei päästetä sisään. Tällöin tuo salasanakehote on vain hämäystä viholliselle: oikeakaan salasana ei johda onnistuneeseen kirjautumiseen. Oletetulle viholliselle ei anneta vinkkiä miksi hänet on torjuttu: tämä tieto jää vain palvelinpään logiin, josta palvelimen ylläpitäjä voi sen antaa yhteyttä yrittävälle, jos yrittäjä saa ylläpitäjän vakuuttumaan että yhteyden on tarkoituskin toimia. Toisaalta logiin kertyvät epäonnistuneet yritykset voivat kertoa ylläpitäjälle että joku on yrittämässä ilkeyksiä, tai laukaista fail2ban:in tai vastaavan automatiikan blokkaamaan paljon epäonnistuneita kirjautumisyrityksiä tekevät IP-osoitteet softapalomuurin tasolla kokonaan joko määräajaksi tai pysyvästi.

Tämän käytöksen takia paras tapa lähteä selvittämään kirjautumisongelmia on yleensä käydä katsomassa sshd-palvelinpään logista mitä se on kirjannut yhteyden torppaamisen syyksi. Tämä logi löytyy yleensä polusta /var/log/auth.log (Debian-sukuiset jakelut, kuten DietPikin taitaa olla) tai /var/log/secure (jakelut joiden juuret ovat RedHatissa), tai sitten komennolla "journalctl -u ssh", jos ko. jakelu käyttää täysin journald-pohjaista logitusta.
 
Eikös tuo nyt kuitenkin riipu siitä, että miten sshd:n AuthenticationMethods on konfiguroitu?

Ainakin jos AuthenticationMethods on oletusarvossaan "any" mutta on asetettu "PasswordAuthentication no", ja "ChallengeResponseAuthentication no", käy juuri kuten kuvasin: sshd antaa salasanakehotteen mutta mikään vastaus ei kelpaa. Ja tämä on se tapa jota olen vanhastaan tottunut käyttämään salasana-autentikoinnin estämiseen, koska se on ollut olemassa jo ennen koko AuthenticationMethods-asetuksen lisäämistä.

Mutta näköjään jos sanotaan "AuthenticationMethods publickey", silloin mahdollisuutta salasanan syöttöön ei edes tarjota. Kiitos; IT-maailma on elinikäistä uuden oppimista täynnä.

Siltikin, vaikka asiakaspäässä yrittäisi "ssh -v" tai vaikka "ssh -vvv":tä, se kertoo vain sen että palvelinpää sanoi "ei pääsyä" kaikille autentikointitavoille mitä asiakaspää pääsi yrittämään, ja se jo tiedettiinkin koska yhteyttä ei muodostunut. Palvelinpään logeista voisi selvitä onko kieltolistalle laitettu käyttäjätunnus tai IP-osoite, vai onko esim. käyttäjän nimeen livahtanut Alt-välilyönti tai vastaava näkymätön merkki, jolloin logissa näkyy tieto että on yritetty kirjautua tunnuksella jota ei ole olemassa.
 
Flatpak asijantuntijoita foorumilla? Tässä kokeilin antaa flatpakeille vielä mahdollisuuden vaikka en ole järin innostunut ihan kaikesta niihin liittyvistä asioista (esim. päivitykset).

Asensin Handbrake softan ja huomasin heti, että tiedostovalintaikkunoissa ei näy Nemossa asettamiani bookmarkkeja (SMB/CIFS jaot, ovat ~/.smb/ kansion alla mountattuna). Jos kopioin ~/.config/gtk-3.0/bookmarks tiedoston ~/.var/app/fr.handbrake.ghb/config/gtk-3.0 hakemistoon niin sitten Handbrakessa näkyy bookmarkit. Miten saisi automaattisesti kaikki Flatpak-softat näyttämään bookmarkit tiedostovalintaikkunoissa? Käsin kopioiminen, tai jopa cronittaminen, tuntuu aika vammaiselta ratkaisulta. Flatpak softilla pitäisi kuitenkin aina olla ajantasalla oleva tieto bookmarkeista (välillä muuttuvat) ja automaattisesti uusille Flatpak softa-asennuksille.

Vinkki Flatpak-aloittelijoille: Flatpak ei ainakaan tällä hetkellä osaa asentaa oikein systeemin teeman vastaavaa Flatpak teemaa. Esim. Handbraken asennus (ensimmäinen Flatpak softa-asennus) asensi nämä:

Koodi:
        ID                                                        Branch             Op             Remote             Download
 1.     fr.handbrake.ghb.Locale                                   stable             i              flathub            < 431,0 kB (partial)
 2.     org.freedesktop.Platform.GL.default                       20.08              i              flathub            < 106,4 MB
 3.     org.freedesktop.Platform.GL.nvidia-450-119-03             1.4                i              flathub             < 99,8 MB
 4.     org.freedesktop.Platform.openh264                         2.0                i              flathub              < 1,5 MB
 5.     org.gnome.Platform.Locale                                 40                 i              flathub            < 333,7 MB (partial)
 6.     org.gtk.Gtk3theme.Mint-Y                                  3.22               i              flathub            < 118,5 kB
 7.     org.gnome.Platform                                        40                 i              flathub            < 363,9 MB
 8.     fr.handbrake.ghb                                          stable             i              flathub             < 38,4 MB

Tuossa tuo org.gtk.Gtk3theme.Mint-Y on väärä teema ja ei edes tunnu toimivan oikein; Mint-Y teemassa pitäisi olla "accent" väri vihreä mutta Flatpak softissa on joku outo sininen accent väri. En tiedä miksi ei osaa oikeaa teemaa ladata automaattisesti, ottaako väärästä paikasta tietoa?:

Koodi:
$ gsettings get org.gnome.desktop.interface gtk-theme
'Mint-Y'
$ gtk-query-settings gtk-theme-name
                     gtk-theme-name: "Mint-Y-Sand"

Oman teeman voi itse toki asentaa, esim. flatpak install org.gtk.Gtk3theme.Mint-Y-Sand ja sen jälkeen (ainakin Handbrakessa) näkyy oikea teema joka on myös systeemissä valittuna.
 
Flatpak sovelluksille voi antaa oikeudet tiettyyn kansioon flatpak override komennolla, olisikohan tästä apua?

Koodi:
flatpak override fr.handbrake.ghb --filesystem=~/.config/gtk-3.0/bookmarks

ja oikeudet voi palauttaa takaisin oletusarvoon komennolla

Koodi:
flatpak override --reset <package_name_here>
 
Flatpak sovelluksille voi antaa oikeudet tiettyyn kansioon flatpak override komennolla, olisikohan tästä apua?
Kiitos vinkistä mutta valitettavasti ei ole apua. Flatpak ei ilmeisesti sitten edes mitenkään yritä lukea noita tietoja vaan menee tylyllä isolated meiningillä.
 
Ihan näin lauantai-illan huumassa kyselen et mikäs/minkälainen tää linuxin passwords and keys softa on? Hitti vai huti? (itsellä kylläkin bitwarden käytössä..) mut ajattelin kysästä..
 
mikäs/minkälainen tää linuxin passwords and keys softa on?
Kyse on Gnomen Seahorse softasta joka menee (ainakin) Linux Mintissä nimellä Passwords and Keys. Henk.kohtasesti en näe tuolla mitään käyttöä jos erittäin hyvä Bitwarden on jo käytössä. En ole tosin varma voiko näitä edes vertailla keskenään, eli onko edes tarkoitettu samaan tarpeeseen. Itsellä näyttäisi tuolla olevan vain Chrome/Chromium (Vivaldi) "Safe Storage" avaimet, ei muuta.
 
Asensin Handbrake softan ja huomasin heti, että tiedostovalintaikkunoissa ei näy Nemossa asettamiani bookmarkkeja (SMB/CIFS jaot, ovat ~/.smb/ kansion alla mountattuna). Jos kopioin ~/.config/gtk-3.0/bookmarks tiedoston ~/.var/app/fr.handbrake.ghb/config/gtk-3.0 hakemistoon niin sitten Handbrakessa näkyy bookmarkit. Miten saisi automaattisesti kaikki Flatpak-softat näyttämään bookmarkit tiedostovalintaikkunoissa? Käsin kopioiminen, tai jopa cronittaminen, tuntuu aika vammaiselta ratkaisulta. Flatpak softilla pitäisi kuitenkin aina olla ajantasalla oleva tieto bookmarkeista (välillä muuttuvat) ja automaattisesti uusille Flatpak softa-asennuksille.
Linkkaa se asetustiedosto sinne?
 
Linkkaa se asetustiedosto sinne?
Etsiskelin ratkaisua jolla ei tarvitsisi manuaalisesti tehdä mitään aina jos asennan uuden Flatpak-softan. Tuo linkkaus kyllä ratkaisisi että bookmarkit ovat aina ajantasalla, se oli hyvä vinkki kiitos ja parempi vaihtoehto kuin kopiointi.
 
Asensin Handbrake softan ja huomasin heti, että tiedostovalintaikkunoissa ei näy Nemossa asettamiani bookmarkkeja
Kokeilin asentaa GIMPin ja siinä bookmarkit näkyy tiedostovalintaikkunoissa ihan ok ilman mitään säätämistä. Tämä taisi sitten olla softakohtaista ongelmaa. GIMPin Flatpakin kanssa taas sitten ei toimi teemat, ilmeisesti koska sitä ei ole vielä portattu GTK3:seen. Työpöytäintegraatiossa hikkoja Flatpakeilla.
 
Kokeilin asentaa GIMPin ja siinä bookmarkit näkyy tiedostovalintaikkunoissa ihan ok ilman mitään säätämistä. Tämä taisi sitten olla softakohtaista ongelmaa. GIMPin Flatpakin kanssa taas sitten ei toimi teemat, ilmeisesti koska sitä ei ole vielä portattu GTK3:seen. Työpöytäintegraatiossa hikkoja Flatpakeilla.

Eikö gimpin saa ihan distron oman paketinhallinnan kautta? Oma mielipide on että distron kautta kaikki mitä vaan saa ja näitä muita vaihtoehtoja sitten kehiin niiden kohdalla joita ei saa.
Ittellä esim. Fedorassa on snapin kautta ainoastaan spotify asennettuna.
 
Kokeilin asentaa GIMPin ja siinä bookmarkit näkyy tiedostovalintaikkunoissa ihan ok ilman mitään säätämistä. Tämä taisi sitten olla softakohtaista ongelmaa. GIMPin Flatpakin kanssa taas sitten ei toimi teemat, ilmeisesti koska sitä ei ole vielä portattu GTK3:seen. Työpöytäintegraatiossa hikkoja Flatpakeilla.
Tosiaan, suositus on, että aina prioritisoidaan jakelun omaa paketinhallintaa ja sieltä asennetaan jos vain mahdollista. Sitten vasta käyttää esim. FlatPak ja ihan viimeisenä vaihtoehtona jos tarjolla niin AppImage. Se vaan on paljon varmempi tapa ajaa "natiivisti" se softa, jos vaan mahdollista, eikä tarvitse kikkailla ylimääräistä...
 
Eikö gimpin saa ihan distron oman paketinhallinnan kautta? Oma mielipide on että distron kautta kaikki mitä vaan saa ja näitä muita vaihtoehtoja sitten kehiin niiden kohdalla joita ei saa.
Osa softasta on vaan niin pirun vanhaa, että haluan osan pysyvän vähän paremmin ajantasalla. Mutta esim. joku LibreOffice, mulla ei tarvi olla siitä mikään uusin versio, mint/ubuntu repon versio käy ihan hyvin. GIMPin kanssa on sellainen homma, että siihen haluan mukaan G'MIC pluginin ja se on distro repon kautta hirveän vanha. Ristiin noita ei taida saada, ei ainakaan toimi kun itse testasin. Eli GIMP reposta ja G'MIC Flatpakkina ei toimi yhteen.

Flatpakit ja AppImaget mitkä otan käyttöön niin ne tulee olla "official", eli softan tekijöiden, en mitään 3rd party julkaisuja ota käyttöön, mitä moni Flatpak esim. on. Ja mietin aina, että onko kuinka iso tekijä, eli voiko luottaa vähän paremmin kun kyse on jostain GIMPin kokoisesta Vs. joku neverhöörd pikkusoftan julkaisija. Ei tosin ole mikään tae turvallisuudesta, aina voi tapahtua kaikkea.

Ittellä esim. Fedorassa on snapin kautta ainoastaan spotify asennettuna.
Itsellä "additional repon" kautta. Kuten myös tällä hetkellä Mega, MKVToolnix, Signal, SpiderOak, Teamviewer ja Vivaldi. PPA:n kautta on Thunderbird (tämä oli tosi vanha distron repossa ainakin siinä vaiheessa kun tätä softaa otin käyttöön) ja qBittorrent. Flatpakeista nyt olisi ainakin tulossa siis GIMP+G'MIC ja Handbrake, AppImaget tällä hetkellä Joplin ja Audacity.

Snappeja en tule ikinä käyttämään monestakin syystä, Linux Mint mielestäni on hyvin tiivistänyt miksi tuota Canonicalin tuotosta pitäisi välttää. Flatpak ja AppImaget jos ihan pakko. Olen vielä win->linux-matkalla ja on vielä jonkin verran windows softaa jolle pitäisi löytää joku korvaava linuxiin (valitettavasti muutama softa tulee jäämään virtualbox+windows varaan) ja ottaa käyttöön joten osa varmaan tulee add.repo/PPA/Flatpak/AppImage kautta vielä.

Sitten vasta käyttää esim. FlatPak ja ihan viimeisenä vaihtoehtona jos tarjolla niin AppImage.
Tietoturvallisuuden takia Flatpak ennen AppImagea? AppImageissa ei ole sandboxaus pakollista, senkö takia? Yksi ongelmahan, jos olen oikein ymmärtänyt, näissä kaikissa Snap/Flatpak/AppImage on se, että miten voi luottaa sen paketin ylläpitäjän päivittämään kaikki kirjastot jos niissä jotain tietoturvaongelmia.
 
Tietoturvallisuuden takia Flatpak ennen AppImagea? AppImageissa ei ole sandboxaus pakollista, senkö takia? Yksi ongelmahan, jos olen oikein ymmärtänyt, näissä kaikissa Snap/Flatpak/AppImage on se, että miten voi luottaa sen paketin ylläpitäjän päivittämään kaikki kirjastot jos niissä jotain tietoturvaongelmia.
Yksi syy tosiaan, miksi AppImagea pikkasen "moititaan", niin riippuen paketin tekijästä, niitä ei aina ajeta sandboxissa ja käsittääkseni sitä ei näe mistään, ainakaan helposti, miten softa on pakattu.
Tietenkin ongelma on enemmän "pakkaajassa" jos ei kerro tuosta, mutta mielestäni olisi hyvä, ettei sallittaisi laisinkaan ajamista ilman sandboxia, liekkö tuolle sitten jokin syy, että tuo valinta on...
Mutta näissäkin, ku on itse tarkkana, niin ei pitäisi olla suurempia ongelmia tietoturvan suhteen...

Itse käytän Rolling release distroja (tällä hetkellä OpenSuse Tumbleweed), niin softa on aina uusinta uutta ja eipä ole tullut vastaan vielä sellaista tarvetta softalle, jota ei olisi löytynyt omista repoista.
 
Viimeksi muokattu:
Osa softasta on vaan niin pirun vanhaa, että haluan osan pysyvän vähän paremmin ajantasalla.

Tuo on joskus ongelma. Itte olen ratkaissut asian niin että jos distron tarjoama puketti on vanha ja uudemmassa on jotain sellaista mitä tartten, niin imasen source rpm:n josta saan .spec filen, imaisen uusimman source paketin softasta ja puukotan .spec fileen uuden version jonka jälkeen buildaan paketit. Joskus selviää ihan pelkällä version muutoksella, joskus tarttee temuta hiukan enemmän jos softaa on distron puolesta patchatty niin patchit ei yleensä toimi uudemman version kanssa suoraan tai sitten ne patchit on jo portattu siihen uuteen versioon.

Itse käytän Rolling release distroja (tällä hetkellä OpenSuse Tumbleweed), niin softa on aina uusinta uutta ja eipä ole tullut vastaan vielä sellaista tarvetta softalle, jota ei olisi löytynyt omista repoista.

Täytyy olla susella sitten pirun tarmokkaat pakettien ylläpitäjät jos tosiaan kaikki on aina uusinta uutta ja paketteja jaksetaan ylläpitää. Fedorassa huomannut vuosien aikana että aina välillä jotain tipahtaa pois kun ylläpitäjä laiskistuu tai katoaa eikä paketille ole löytynyt uutta ylläpitäjää.
Sitten on joitain suht hyviä 3rd party repoja, mutta niissä tahtoo olla vielä laiskempaa se ylläpito. Esim nyt handbrake on v1.3.3 kun uusin on 1.4.0.
 
Viimeksi muokattu:
Täytyy olla susella sitten pirun tarmokkaat pakettien ylläpitäjät jos tosiaan kaikki on aina uusinta uutta ja paketteja jaksetaan ylläpitää. Fedorassa huomannut vuosien aikana että aina välillä jotain tipahtaa pois kun ylläpitäjä laiskistuu tai katoaa eikä paketille ole löytynyt uutta ylläpitäjää.
Sitten on joitain suht hyviä 3rd party repoja, mutta niissä tahtoo olla vielä laiskempaa se ylläpito. Esim nyt handbrake on v1.3.3 kun uusin on 1.4.0.
En nyt niin tarkkaan ole seurannut, mutta aikas tuoreita versioita on ainakin niistä softista, joita itse tarvitsen ja eikä ole ollut ongelmia niiden kanssa, taikka puutteita ominaisuuksissa omiin tarpeisiin.
Handbrake näkyy olevan 1.4.0, GIMP 2.10.24, LibreOffice 7.1.5.2, eli aikas tuoretta ku tsekkasin huvikseni...

Kaikki on tietenkin suhteellista ja paljon käyttäjän tarpeista kiinni, jokainen valitkoon sen mukaan, itse käyttänyt rolling release jakeluita vuosikausia ja palvellut erittäin hyvin tarpeitani ja olen ollut tyytyväinen.
 
Viimeksi muokattu:
Yksi syy tosiaan, miksi AppImagea pikkasen "moititaan", niin riippuen paketin tekijästä, niitä ei aina ajeta sandboxissa
Tähän vähän liittyen, kun asensin Flatseal appsin jolla voi tarkastella/hallita Flatpak appsien käyttöoikeuksia GUIn kautta, niin huomasin heti, että kaikissa muissa Flatpak appsissa mitkä tällä hetkellä asennettuna (GIMP, Handbrake, GtkHash), on defaulttina "filesystem=host" oikeudet.

BTW. Se Handbrake ja bookmark-ongelma, se ratkeaa helposti kun antaa Flatseal:in tai terminaalin kautta yhden käyttöoikeuden: flatpak override --user fr.handbrake.ghb --filesystem=xdg-config/gtk-3.0 EDIT: tai jättää --user pois ja koko komento sudolla niin sääntö tulee kaikille.
 
Oi tuoreus. Itse olen käyttänyt nyt Endeavour OS:sia. Joka päivä tulee sellainen 5-10 päivitystä :) (ai niin, voinhan mä laittaa sen vaikka viikonvälein tarkistamaan...). Muistelen kun wintoosaa haukuttiin että aina pitää käynnistää uudestaan, niin tässä on ylitetty sekin kun kerneli päivittyy niin usein. Mutta onkin sitten nopea että naps. Ja ensimmäinen arch joka ei ole hajonnut kättelyssä, itse kun olen vain puoli- ellei jopa vain neljäsosasäätäjä. Tosin tässä on ihan kätevä päivitysohjelma. Ikävä tosin välillä tulee kun välillä työpöytäkoneessa ei toimi PopOssin TileWindows, se on vaan niin kätsy. Läppärissä toimii.
 
Viimeksi muokattu:
polkit. Mikä homma? Koitapa tehdä AD:ssä määriteltu admin group, jolla olisi oikeudet ylläpitää konetta. Käy ilmi, että polkitin policyt ja rulet, joita softien asennuspaketit tuovat, on sidottu kovakoodaten "sudo"-grouppiin tai toisaalla "wheel"-grouppiin. Eli ei riitä että käyttäjät liitetään AD:ssä olevaan erilliseen ryhmään, jolle annetaan täydet sudo oikeudet. Ja noi kovakoodatut group-määrittelyt ovat tiedostoissa, joissa on sellaista magiikka-paskaa ettei todellakaan tee mieli ottaa niitä omaan ylläpitoon ( taikka sed:itellä niihin muutoksia).

Lisäksi asennuspakettien tuomissa policy- ja rule-tiedostoissa on sidottu määrittelyt siihen onko käyttäjä paikallinen. Seurauksena esim. VDI-ympäristössä pitäisi taas ottaa täysin omaan ylläpitoon noi kaikki magiikkaa sisältävät tiedostot, että saisi remote käyttäjillekin admin-oikeudet.

Ja meni melko kauan ymmärtää, että Ubuntussa rule-tiedostot eivät ole käytössä ( vaikka softapaketit asentavat niitä ), koska Ubuntu käyttää melkosen vanhaa polkit-versiota. Rule-tiedostot ovat javascriptiä, ja vaativat siten javascript enginen.

Vähän silleen rant-tyyppisesti: polkit, wtf?
 
Viimeksi muokattu:
Oi tuoreus. Itse olen käyttänyt nyt Endeavour OS:sia. Joka päivä tulee sellainen 5-10 päivitystä :) (ai niin, voinhan mä laittaa sen vaikka viikonvälein tarkistamaan...). Muistelen kun wintoosaa haukuttiin että aina pitää käynnistää uudestaan, niin tässä on ylitetty sekin kun kerneli päivittyy niin usein. Mutta onkin sitten nopea että naps. Ja ensimmäinen arch joka ei ole hajonnut kättelyssä, itse kun olen vain puoli- ellei jopa vain neljäsosasäätäjä. Tosin tässä on ihan kätevä päivitysohjelma. Ikävä tosin välillä tulee kun välillä työpöytäkoneessa ei toimi PopOssin TileWindows, se on vaan niin kätsy. Läppärissä toimii.

Kokelin lyhyen aikaa mediapönttöön Manjaroa kunnes ymmärsin että näissä kaikissa Arch johdannaisissa on harvinaisen idioottimainen kernelinpäivitys joka käytännössä pakottaa boottaamaan että päivitys menee kokonaan. Ei tullut siis Manjarosta työjuhtaa. En henkilökohtaisesti näe tarvetta kernelin päivityksen takia bootata ellei ole paikattu jotakin universumin suurinta reikää taikka dataa korruptoivaa bugia.

Ja meni melko kauan ymmärtää, että Ubuntussa rule-tiedostot eivät ole käytössä ( vaikka softapaketit asentavat niitä ), koska Ubuntu käyttää melkosen vanhaa polkit-versiota. Rule-tiedostot ovat javascriptiä, ja vaativat siten javascript enginen.

Vähän silleen rant-tyyppisesti: polkit, wtf?

Ottamatta kantaa tuohon AD hommaan, tuo polkit on kyllä perse viritys. Javascriptiä noinkin olennaiseen palikkaan? Todellakin wtf.

Ja nimim. Gentookuski, tuo sonta on tehty käyttämään SpiderMonkeytä joka on perkeleellisen raskas käännettävä ja ottaa mopolla läppärilläni luokkaa tunteja eikä minuutteja. En tarvitse PolKitistä muuta kuin minimin, eikä SpiderMonkeytäkään tarvita muuhun kuin tuohon hökötykseen. Siksi on käytössä kotipolttoinen polkit ebuildi joka patchaa sen käyttämään Duktapea. Ihan riittävästi raskaita paketteja ilman yhtä joutavaa.
 
Kokeilin manjaro kde:tä näin windowsiin tottuneena. Helppohan tuo oli asentaa läppäriin ja ei paljoa bugeja ynnä muuta. Oikeastaan hidas skrollaus hiirellä nettiselaimissa joita kokeilin oli ongelma ja kineettisen selauksen puute touchpadilla harmitti. Myöskään integroitu näyttis oli vähän hidas selatessa tai sitten se johtui vaan tuosta skrollauksesta jotenkin. Tekstin reunan pehmennys oli vähän puutteellista myös. Olisi myös kiva jos taskbarin kuvakkeet saisi leveämmäksi. Parasta oli nopeat päivitykset, no border valinta ja dolphin tiedostojen selaus Onko noihin aikasemmin mainittuihin skrollaus ongelmiin tiedossa tai tulossa mitään ratkaisua tai kenties jotain toista distroa?
 
Itselle kunnollisen Onedrive tuen puuttuminen ollut yksi ongelma Linuxin kanssa kun ei aina jaksa käytellä webbikäliä kun se on hieman kömpelöä.

Nyt kuitenkin löytyi palikka joka tuntuisi toimivan varsin mallikkaasti omiin tarpeisiin

 
Kokelin lyhyen aikaa mediapönttöön Manjaroa kunnes ymmärsin että näissä kaikissa Arch johdannaisissa on harvinaisen idioottimainen kernelinpäivitys joka käytännössä pakottaa boottaamaan että päivitys menee kokonaan. Ei tullut siis Manjarosta työjuhtaa. En henkilökohtaisesti näe tarvetta kernelin päivityksen takia bootata ellei ole paikattu jotakin universumin suurinta reikää taikka dataa korruptoivaa bugia.
Eikai sitä konetta ole pakko heti bootata vaikka uusi kerneli tulisikin. Boottaa sitten kun on parempi aika jos ylimääräinen boottaus aiheuttaa vaivaa. Tosin missä käyttiksessä kernelin päivitys tulee käyttöön heti ilman boottausta?

(IMHO) Manjaro tosin yksi huonoimmista Arch-johdannaisista joka hajoaa todella nopeasti ja helposti,
 
Itselle kunnollisen Onedrive tuen puuttuminen ollut yksi ongelma Linuxin kanssa kun ei aina jaksa käytellä webbikäliä kun se on hieman kömpelöä.

Nyt kuitenkin löytyi palikka joka tuntuisi toimivan varsin mallikkaasti omiin tarpeisiin


Kiitos vinkistä. Olen taistellut aikaisempien kehnojen Linux-OneDrive-clienttien kanssa, mutta tuota en ollut huomannut. Vaikuttaa hyvältä.

Tosin missä käyttiksessä kernelin päivitys tulee käyttöön heti ilman boottausta?

Linuxissa tuo on mahdollista, jos siihen on erityinen tarve: How to update Linux Kernel without rebooting? - Dade2
 
Kiitos vinkistä. Olen taistellut aikaisempien kehnojen Linux-OneDrive-clienttien kanssa, mutta tuota en ollut huomannut. Vaikuttaa hyvältä.
Itsellä nyt ollut ~viikon verran ajossa tuo ja toiminut oikein nätisti. Koneen bootin yhteydessä tuntuu hetki kestävän että tuo clientti starttaa (olettaen että on laittanut sieltä se auto mountin päälle) mutta muutoin en ole vielä huomannut ongelmia.
Linuxissa tuo on mahdollista, jos siihen on erityinen tarve: How to update Linux Kernel without rebooting? - Dade2
Taas oppi jotain uutta. Ajattelin että tää olis ollu jonku distron spessuominaisuus. Ei sinällään että itsellä olisi tuollaiselle tarvetta, mutta varmaan jossain tilateissa ihan kätevä.
 
Juu, nykyään tiedostojärjestelmät ovat yllättävän vikasietoisia ja tietenkin jos jotain serveriä tms pyörittää niin suosiolla kannattaa sellaiseen valitakin sellainen fs joka sietää sähkökatkon kaltaisia ylläreitä edes kohtuullisesti. Joskus ext2-aikakautena joku sähkökatko saattoikin sotkea järjestelmän kunnolla mutta eipä näillä nykyaikaisilla tiedostojärjestelmillä enää tarvitse paljoa pelätä.
Tähän liittyen kysymys. Mulla on Ubuntu 18.04 -serveri (ext4) kahden edellisen sähkökatkon jälkeen vaatinut manuaalisia toimenpiteitä tiedostojärjestelmän korjaamiseksi. En ole tarkkaan lukenut mitä se sanoo kun yrittää buutata, mutta y:tä ja a:ta hakkaamalla pääsee eteenpäin ja lopulta kaikki korjaantuu. Onko tämä normaalia vai onko tuo merkki jostain viasta? Sähkökatkojen aikana kone on ollut lähinnä idlaamassa. Kovalevy on aika täynnä, jos sillä on jotain merkitystä.
 
Eikai sitä konetta ole pakko heti bootata vaikka uusi kerneli tulisikin. Boottaa sitten kun on parempi aika jos ylimääräinen boottaus aiheuttaa vaivaa. Tosin missä käyttiksessä kernelin päivitys tulee käyttöön heti ilman boottausta?

Täytyy tunnustaa että tästä kokeilusta on jo sen verran aikaa etten enää edes muista yksityiskohtia, voihan kyseessä olla user errorkin. Paketinhallinta kuitenkin nosti kädet pystyyn kunnes oli sen himoitseman bootin tehnyt. Tai ehkä ymmärsin väärin ja kyseessä oli pelkästään Manjaron vammailua eikä Archin peruja.

Mutta en tarkoittanutkaan että sen uuden kernelin pitäisi tulla käyttöön ilman boottia, pointti oli että sillä että ei sen tarvitsekaan tulla. Paketinhallinta voi hyvin asennella sen uuden kernelipaketin jolloin se on käytössä seuraavan bootin jälkeen, oli se sitten tunnin tai vuoden päästä. Nuo normaalin päivityskierroksen mukana tulevat kernelipäivitykset ovat tavallisesti täysin yhdentekeviä, boottaaminen pelkästään distron vakiokernelin päivityttyä versiosta x.x.12 versioon x.x.13 harvemmin on tarpeellista.
 
Vaikka manjaro kokeiluni tällä viikkolla oli vähän negatiivinen, niin laitoin vielä ubuntun testiin. Vaikka käyttö ei ole ihan optimia vieläkään varsinkaan skrollauksen suhteen ja fontti renderöinti ei ole ihan winukan tasolla, on kumminkin käyttö ihan sujuvaa. Positiivisina puolina mm. tietoturva pitäisi olla paremmalla tolalla, kdeConnectille (gsConnect) on löytynyt jo käyttöä, ja aiemmin mainitut sujuvat päivitykset. Myös vanhan kannettavan hdmi portti heräsi eloon, ilmeisesti sen kanssa on joku ajuri ongelma winukalla. Myös nykyinen läppärin touchpadi ongelma joka on on ollut huollosakin asti, ei vaivaa ubuntulla. Eiköhän tämä ubuntu päivittäiseen käyttöön jää tästä eteenpäin :tup:
 
Täytyy tunnustaa että tästä kokeilusta on jo sen verran aikaa etten enää edes muista yksityiskohtia, voihan kyseessä olla user errorkin. Paketinhallinta kuitenkin nosti kädet pystyyn kunnes oli sen himoitseman bootin tehnyt. Tai ehkä ymmärsin väärin ja kyseessä oli pelkästään Manjaron vammailua eikä Archin peruja.

Mutta en tarkoittanutkaan että sen uuden kernelin pitäisi tulla käyttöön ilman boottia, pointti oli että sillä että ei sen tarvitsekaan tulla. Paketinhallinta voi hyvin asennella sen uuden kernelipaketin jolloin se on käytössä seuraavan bootin jälkeen, oli se sitten tunnin tai vuoden päästä.
Käytän itse Archissa sekä vakiokerneliä läppärillä että omia kerneleitä pöytäkoneella (+dkms:llä jotain ajureita), eikä ole ikinä tarvinnut pakotetusti bootata konetta päivityksen takia. Toki jos päivität uudempaan minor-versioon etkä vaan asenna uutta patch-versiota, uusissa kerneleissä joskus tulee uusia ominaisuuksia kuten esim. uusia pakkausformaatteja levyjärjestelmiin. Lisäksi Archissa on tuo ominaisuus vakiona, että se poistaa vanhan kernelin päivittäessä, joten et voi ladata moduuleita päivityksen jälkeen ellet palauta jotenkin vanhaa kerneliä. Siihen saa tosin paikan, jolla vanhan voi jättää talteen tätä varten.

Nuo normaalin päivityskierroksen mukana tulevat kernelipäivitykset ovat tavallisesti täysin yhdentekeviä, boottaaminen pelkästään distron vakiokernelin päivityttyä versiosta x.x.12 versioon x.x.13 harvemmin on tarpeellista.
Boottaaminen on tarpeen lähinnä jos tarvii uudempaa mikrokoodia, uudempia firmwareja, uudempaa kerneliä ominaisuuksien/bugikorjausten takia, uudempaa bootloaderia tai userspacessa joku prosessi paskoo itsensä pitkässä käytössä. Esim. levyt saa probetettua uudestaan, systemd osaa ladata itsensä uudestaan päivityksen jälkeen. Jopa kernel-moduulit voi poistaa ja ladata uudestaan tietyin reunaehdoin. Nykyisin kotikäytössä ehkä suurin motivaatio bootata uuteen kerneliin on juuri nuo stabiiliusjutut ja esim. amdgpu-ajureissa tulee silloin tällöin aika kriittisten bugien korjauksia, jotka auttavat juuri tuota koneen pitämistä päällä viikkoja, kun gpu-ajurien kaatuminen voi vaatia koko koneen resetoinnin, kun ei vaan kuva palaudu.
 
Oliko Linuxille jotain apusoftaa millä saisi konfiguroitua Logitech MX Master3:n nappeja.

Muistan joskus jotain uutta gui palikka kokeilleensa, mutta oli silloin vielä raakile ettei sisältänyt oikein mitään ominaisuuksia ja nyt en enää nimeä muista.
 

Statistiikka

Viestiketjuista
258 389
Viestejä
4 489 658
Jäsenet
74 150
Uusin jäsen
JM11

Hinta.fi

Back
Ylös Bottom