Linux-kysymyksiä & yleistä keskustelua Linuxista

Tuli nyt ajankohtaiseksi ihmetellä tarkemmin linuxin tiedostojen sorttauksen ihmeellisyyttä. Huomasin, että Ääkköset sortataan mun mint asennuksessa kuin ne olisi Aakkosia. Pitkän googlailun jälkeen tuli turhautumista.

Olin aiemmin vain gui:n puolelta vaihtanut locale-asetuksia, eli suomea region ja timeformattiin ja usaenkkua kieleen.

locale-komento näytti tältä:
Koodi:
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=fi_FI.UTF-8
LC_TIME=fi_FI.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=fi_FI.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=fi_FI.UTF-8
LC_NAME=fi_FI.UTF-8
LC_ADDRESS=fi_FI.UTF-8
LC_TELEPHONE=fi_FI.UTF-8
LC_MEASUREMENT=fi_FI.UTF-8
LC_IDENTIFICATION=fi_FI.UTF-8
LC_ALL=

Syypää ääkkösten sorttaukseen oli siis LC_COLLATE jonka muutin fi_FI.UTF-8.

Onko LC_CTYPE:llä mitään merkitystä, että onko se en_US.UTF-8 tai fi_FI.UTF-8? Ja kannattaako se olla vaan sama kuin LANG?

Eksyin googlatessa lukemaan githubiin mintin tiedostohallintasoftan, Nemon sorttausvalituksia ja jos käsitin oikein, niin perusongelma on lähtöisin glib-projektista ja kuulemma ei kannata odotella, että he korjaisivat tilannetta mitenkään ("it was written as documented, the end." tjsp.). Jotkut ovat tehneet omia localeita jossa ovat fiksanneet jotain sorttausjuttuja, jotkut käyttävät jotain hackia korjaamaan, ja joku fiksaa suoraan nemon koodia ja kääntää sen itse omalle koneelle.

Mitä nyt lukenut ja testannut vähän itse niin sopivaa sorttaussysteemiä ei tahdo saada. en_US.UTF-8 tai fi_FI.UTF-8 käyttäessä näyttäisi siltä, että sorttauksessa merkitsee vain alfanumeeriset merkit, vähän väliä onko tiedostonimissä välejä tai erikoismerkkejä. Esim.:
Koodi:
S-kaupat
soidinmenot
S-Pankki
Näissä on onneksi se, että isot ja pienet kirjaimet eivät vaikuta järjestykseen mutta tosiaan erikoismerkit ei vaikuta, esim. huutomerkillä alkava sortataan sen mukaan mikä siinä tiedostonimessä on seuraava alfanumeerinen merkki. Paras IMO olisi, että sorttaus olisi näin:
Koodi:
S-kaupat
S-Pankki
soidinmenot
Windowsissa command prompti (tai powershell) noin sen näyttää, mutta omaksi yllätyksekseni, gui:n puolella file manager ei, se näyttää kuten linuksissa.

Sitten jos kokeilee LC_COLLATE=C asetusta niin sorttaus näyttäisi tapahtuvan ASCII-merkistön järjestyksessä, mistä aiheutuu IMO suuri ongelma siitä, että isot kirjaimet tulevat aina ennen pieniä kirjaimia sorttauksessa. Esim. (katso miten iso "M" on ennen kuin pienellä olevat "a":t alkavat:
Koodi:
! A
%
&
( A
.
..
.A
.a
.aaa
1
9
A
A Aaa
Aaa
M
[ A
a
aa
{ A
Äää
ä
Lisäksi erikoismerkit ei ihan ole mukavassa sorttausjärjestyksessä tuossa.

asciifull.gif


Ja kaiken päälle esim. Nemossa on omat hardkoodaukset lisäksi; numerot tulee ekaksi ja pisteellä alkavat loppuun.

Paras sorttausjärjestys olisi IMO "erikoismerkit - numerot - aakkoset (case insensitive)". Käsittääkseni windowsissa sorttaus on tuollainen. Saisiko linuksiin tuollaista?
 
Päivitystä tilanteeseen. Ei auttanut swap file. Tosin toiminta ehkä(?) muuttui hieman kaatumisen jälkeen. Sain siis ihan KDE:n kautta terminaalin auki (konsole) ja sieltä "dmesg -wH". Tämä copy pastella Kate:n ja sain tallennettua. Mikään muu kuin KDE:n "omat" sovellukset ei tosin aukea? System monitori (KsysGuard) näytti kummallisia. Muistia ei ollut käytössä lainkaan, swappia ei ollut käytössä, mutta kaksi CPU corea oli koko ajan 100% loadissa ja niitä käytti ilmeisesti spotify(asennettu AUR kautta). Tapoin prosessin niin CPU-käyttö meni nollaan. Kuitenkaan mikään sovellus ei aukea. Päätin rebootata, mutta KDE-menun kautta kaikki jäätyi taas paikalleen kun koitti painaa reboot.
Pastebin dmesg -wH tuloksesta. Nyt en ainakaan itse löytänyt tästä mitään muistiongelmaan viittaavaa? Tämän lisäksi Dota2 ei ole ollut koko tällä käynnistyksellä päällä. Lähes mitään en tuosta ymmärrä, mutta jotenkin näyttäsi, että tuo dmesg -wH on jotenkin vasta ton kaatumisen jälkeistä dataa?


Edit.Alkanut nyt epäilemään että voiko tuo Spotify jotenkin sotkea kaiken. Muistikuvien mukaan se on ollut aina auki ongelman ilmetessä. Tuon swapon teon jälkeen ongelmaa ei hetkeen tullut, mutta ei tainnut olla spotifykään päällä silloin...

Olisiko @JiiPee tai @TenderBeef ideoita mitä seuraavaksi?
 
Viimeksi muokattu:
Muistia ei ollut käytössä lainkaan, swappia ei ollut käytössä
Jotain vähän outoa tapahtuu, todella vaikea sanoa, en ole edes mikään linux-ekspertti, vasta hiljattain siirtynyt linuxin käyttäjäksi ja opin tiellä kovasti ollaan vielä. Vilaisin läpi postaamasi lokin ja ei siitä oikein mikään osunut silmään mikä olisi vialla. Onko distrollesi jotain foorumia josta voisit kysyä?

kaksi CPU corea oli koko ajan 100% loadissa ja niitä käytti ilmeisesti spotify(asennettu AUR kautta)
Spotify taitaa olla chrome/electron softa, joten ongelmana tuossa voi olla softassa päällä oleva laitteistokiihdytys joka ainakin itsellä tuottaa ongelmia nvidian ajureiden kanssa joidenkin tuollaisten softien kanssa tietyissä tilanteissa (itsellä lähinnä ongelmaa on hibernate-tilasta herättämisen jälkeen).

BTW. Taitaa olla niin, että foorumilla jos lisäät lainauksen toiselta käyttäjältä, tai tagitat käyttäjän omaa viestiäsi editoimalla niin niistä ei tule mitään ilmoitusta kyseisille käyttäjille. Huomasin vasta nyt lisäyksesi.
 
Viimeksi muokattu:
Onko kellään mitään tietoa tästä? Googletuksella saa vähän epämääräisen kuvan/eriäviä selostuksia mitä tuo tekee.

Nuo ovat osittain rinnakkaiset mutta osittain myös erilliset asetukset. Luultavasti taustalla ovat Historialliset Syyt™ enkä itsekään osaa tarkalleenottaen sanoa missä toinen asetus vaikuttaa ja toinen ei.


Ei ehkä ole kovin pitkän pohdinnan arvoinen asia, asettaa molemmat samaan arvoon ja kovaa ajoa.
 
Onko kellään mitään tietoa tästä? Googletuksella saa vähän epämääräisen kuvan/eriäviä selostuksia mitä tuo tekee.

Komento "man 7 locale" kertoo näiden eri locale-asetusten merkityksen.

Tuolla LC_CTYPE-asetuksella tuskin on suurempaa jos mitään merkitystä kahden eri kielisen UTF-8 -asetuksen välillä, mutta erilaisten vanhempien merkistöjen, esim. ISO-8859 ja ISO-646 varianttien välillä tällä asetuksella on suuri merkitys, koska niissä merkistöissä on samoilla paikoilla ihan eri merkkejä, jolloin merkkien tunnistaminen kirjaimiksi tai niiden muuttaminen isosta pieneksi jne. ei toimi, ellei softa tiedä, mitkä numerokoodit vastaavat mitäkin merkkejä. Nykyään kun kaikki on UTF-8:aa, asiaan ei tarvitse kiinnittää samalla tavalla huomiota kuin entisaikoina.

edit, lisäys:

Kun ajat komennon "LC_CTYPE=fi_FI.UTF-8 locale -k LC_CTYPE" ja vertaat sen outputtia komennon "LC_CTYPE=en_US.UTF-8 locale -k LC_CTYPE" outputtiin, huomaat, ettei näillä ole mitään eroa. Eli on ihan se ja sama kumpaa käytät.
 
Viimeksi muokattu:
Jos joku Gigabyte X570 lankun omistaja haluaa saada kaikki sensori tiedot näkyviin niin tässä pari niksiä että it8688 piirin tiedot saa näkyviin.

Asenna it87-dkms, löytyy mm. arch pohjaisille distroille AUR reposta AUR (en) - it87-dkms-git

Jos sensors-detect komennolla ei löydy uusia anturi tietoja ja vanhatkin katosi niin siihen pitäisi auttaa uuden confin lisäys etc/modprobe.d/ kansioon.

etc/modprobe.d/it87.conf
Koodi:
options it87 ignore_resource_conflict=1


Osa jännitteistä näkyy väärin ja nimet on geneerisiä mutta niitä voi muokata taas omalla conf tiedostolla. Tein omalle Aorus Pro:lle tälläisen netistä löytämieni tietojen perusteella ja vaikuttaa vastaavan samoja arvoja kuin HWinfo windowssissa. Sama conffi ei välttämättä näytä oikein muissa emoissa mutta voi tuota pohjana käyttää.

etc/sensors.d/gigabyte-x570.conf
Koodi:
chip "it8792-*"
    label in1 "DDR VTT"
    label in2 "Chipset"
    label in4 "CPU VDD18"
    label in5 "DDR VPP/PM_CLDO12"
    
    label fan3 "System 4"
    label fan1 "System 5 Pump"
    label fan2 "System 6 Pump"
    label temp1 "System 2"
    label temp2 "EC_TEMP2"
    label temp3 "PCIEX16_2"

chip "it8688-*"
    label in0 "Vcore"
    label in1 "+3.3V"
    compute in1 1.65*@,@/1.65
    label in2 "+12V"
    compute  in2  @ * (72/12), @ / (72/12)
    label in3 "+5V"
    compute in3 2.5*@,@/2.5
    label in4 "CPU Vcore SOC"
    label in5 "CPU VDDP"
    label in6 "DRAM A/B"
        
    label fan1 "CPU_FAN"
    label fan2 "SYS_FAN1"
    label fan3 "SYS_FAN2"
    label fan4 "Chipset fan"
    label fan5 "CPU_OPT"

    label temp1 "SYSTEM1"
    label temp2 "EC_TEMP1"
    label temp3 "CPU"
    label temp4 "PCIEX16_1"
    label temp5 "VRM"
    label temp6 "Chipset"


Jos kaikki meni oikein niin terminaalista pitäisi sensors komennolla tulla jotain tämän näköistä.
it8688-isa-0a40
Adapter: ISA adapter
Vcore: 996.00 mV (min = +0.00 V, max = +3.06 V)
+3.3V: 3.35 V (min = +0.00 V, max = +5.05 V)
+12V: 12.17 V (min = +0.00 V, max = +18.36 V)
+5V: 5.07 V (min = +0.00 V, max = +7.65 V)
CPU Vcore SOC: 1.04 V (min = +0.00 V, max = +3.06 V)
CPU VDDP: 912.00 mV (min = +0.00 V, max = +3.06 V)
DRAM A/B: 1.49 V (min = +0.00 V, max = +3.06 V)
3VSB: 3.31 V (min = +0.00 V, max = +6.12 V)
Vbat: 3.24 V
CPU_FAN: 923 RPM (min = 0 RPM)
SYS_FAN1: 480 RPM (min = 0 RPM)
SYS_FAN2: 581 RPM (min = 0 RPM)
Chipset fan: 2376 RPM (min = 0 RPM)
CPU_OPT: 1138 RPM (min = 0 RPM)
SYSTEM1: +32.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
EC_TEMP1: -55.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
CPU: +34.0°C (low = +127.0°C, high = +127.0°C) sensor = AMD AMDSI
PCIEX16_1: +40.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
VRM: +39.0°C (low = +0.0°C, high = -125.0°C) sensor = thermistor
Chipset: +41.0°C (low = -16.0°C, high = +90.0°C) sensor = thermistor
intrusion0: OK

zenpower-pci-00c3
Adapter: PCI adapter
SVI2_Core: 1.49 V
SVI2_SoC: 1.04 V
Tdie: +34.9°C (high = +95.0°C)
Tctl: +34.9°C
Tccd1: +41.0°C
SVI2_P_Core: 22.64 W
SVI2_P_SoC: 8.91 W
SVI2_C_Core: 15.15 A
SVI2_C_SoC: 8.53 A

acpitz-acpi-0
Adapter: ACPI interface
temp1: +16.8°C (crit = +20.8°C)
temp2: +16.8°C (crit = +20.8°C)

it8792-isa-0a60
Adapter: ISA adapter
in0: 1.79 V (min = +0.00 V, max = +2.78 V)
DDR VTT: 730.00 mV (min = +0.00 V, max = +2.78 V)
Chipset: 981.00 mV (min = +0.00 V, max = +2.78 V)
in3: 2.02 V (min = +0.00 V, max = +2.78 V)
CPU VDD18: 1.79 V (min = +0.00 V, max = +2.78 V)
DDR VPP/PM_CLDO12: 1.18 V (min = +0.00 V, max = +2.78 V)
in6: 2.78 V (min = +0.00 V, max = +2.78 V) ALARM
3VSB: 3.33 V (min = +0.00 V, max = +5.56 V)
Vbat: 3.31 V
System 5 Pump: 490 RPM (min = 0 RPM)
System 6 Pump: 0 RPM (min = 0 RPM)
System 4: 688 RPM (min = 0 RPM)
System 2: +33.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
EC_TEMP2: -55.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
PCIEX16_2: +32.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
intrusion0: ALARM

ucsi_source_psy_0_00081-i2c-0-08
Adapter: NVIDIA GPU I2C adapter
in0: 0.00 V (min = +0.00 V, max = +0.00 V)
curr1: 0.00 A (max = +0.00 A)

nvme-pci-0100
Adapter: PCI adapter
Composite: +38.9°C (low = -60.1°C, high = +89.8°C)
(crit = +94.8°C)
 
Asuksen WMI härpäkettä tukevat emot saanu ihan kernel tuen sensorien lukuun.

Koodi:
[root@nas ~]# sensors
asus_wmi_sensors-virtual-0
Adapter: Virtual device
CPU Core Voltage:        916.00 mV
CPU SOC Voltage:         894.00 mV
DRAM Voltage:              1.20 V
VDDP Voltage:            916.00 mV
1.8V PLL Voltage:          1.83 V
+12V Voltage:             11.90 V
+5V Voltage:               5.04 V
3VSB Voltage:              3.33 V
VBAT Voltage:              3.10 V
AVCC3 Voltage:             3.31 V
SB 1.05V Voltage:          1.04 V
CPU Fan:                 1059 RPM
Chassis Fan 1:           1247 RPM
Chassis Fan 2:           1027 RPM
Chassis Fan 3:            733 RPM
AIO Pump:                   0 RPM
Water Pump:                 0 RPM
CPU OPT:                    0 RPM
Water Flow:                 0 RPM
CPU Temperature:          +36.0°C
CPU Socket Temperature:   +53.0°C
Motherboard Temperature:  +33.0°C
Chipset Temperature:      +53.0°C
Tsensor 1 Temperature:   +216.0°C
CPU VRM Temperature:      +36.0°C
Water In:                +216.0°C
Water Out:               +216.0°C
CPU VRM Output Current:    4.00 A

Tästä näkee mitkä lankut tuettuna ja tuki on lisätty 5.17 kerneliin.

Koodi:
[root@nas ~]# modinfo asus_wmi_sensors | grep alias
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGZENITHEXTREMEALPHA*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGZENITHEXTREME*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGSTRIXX470-IGAMING*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGSTRIXX470-FGAMING*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGSTRIXX399-EGAMING*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGSTRIXB450-IGAMING*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGSTRIXB450-FGAMING*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGSTRIXB450-EGAMING*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGCROSSHAIRVIIHERO(WI-FI)*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGCROSSHAIRVIIHERO*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGCROSSHAIRVIHERO(WI-FIAC)*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*CROSSHAIRVIHERO*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*ROGCROSSHAIRVIEXTREME*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*PRIMEX470-PRO*:
alias:          dmi*:rvn*ASUSTeKCOMPUTERINC.*:rn*PRIMEX399-A*:

500 sarjan emoissa asus luopui tuosta WMI härvelistä ilmeisesti.
 
Näköjään gigabyte-wmi pitäis kans olla kernelissä nykyään. Gigabyte Motherboard WMI Temperature Driver Queued Ahead Of Linux 5.13 - Phoronix

Pitää tutkia saisko tällä emolla tuollakin ajurilla kaikki näkyviin.

edit. Ei ainakaan tuetuista emoista löydy ja pika vilkasulla kaikkissa tuon moduulin listalla olevissa emoissa on vähemmän sensoreita ja varmaan käytössä yksi piiri. Eli jatkan vielä vanhalla metodilla.
 
Viimeksi muokattu:
Onko näin, että (K)Ubuntussa (22.04 LTS) ei saa esiasennettua Firefoxia asetettua oletusselaimeksi vastaamalla "Allow" ja "Yes" ainakun sitä kysytään? Ja eikö tosiaankaan esiasennettu Firefox (ilmeisesti snap-paketti) päivity kun vedän onelinerin: sudo apt update && sudo apt upgrade && sudo apt dist-upgrade? On pakko päivittää FF erikseen komennolla sudo snap refresh firefox?

Mitä v...ua?

Älkää käsittäkö väärin, pidän Ubuntusta paljon (palvelimena), mutta nyt on tässä suht lähiaikoina alkanyt vituttamaan nuo yllämainitut ongelmat, joita ei ollut silloin kun tämän Kubuntun asensin tähän koneeseen... Niin onko tämä vain Kubuntun ongelma, vai Ubuntun ongelma yleisesti?
 
Onko näin, että (K)Ubuntussa (22.04 LTS) ei saa esiasennettua Firefoxia asetettua oletusselaimeksi vastaamalla "Allow" ja "Yes" ainakun sitä kysytään? Ja eikö tosiaankaan esiasennettu Firefox (ilmeisesti snap-paketti) päivity kun vedän onelinerin: sudo apt update && sudo apt upgrade && sudo apt dist-upgrade? On pakko päivittää FF erikseen komennolla sudo snap refresh firefox?

Mitä v...ua?

En oletusselaimeen pysty ottamaan kantaa, ainoa Ubuntu josta näinä päivinä joudun kärsimään (sekin työn puolesta) on uunituore 18.04 jossa tuota snappiperseilyä ei olla vielä viety niin pitkälle että sen kanssa tarvitsisi alkaa painimaan. Mutta asiahan lienee kaikessa yksinkertaisuudessaan niin että apt, joka on frontend Debianista periytyvälle dpkg:lle joka taasen käpistelee perinteisiä deb-paketteja, ei tiedä eikä välitä snap-pökäleistä tuon taivaallista.

Snap on taas vaihteeksi Canonicalin NIH pelleilyä ja rinnakkainen tuon dpkg:n kanssa. Sen daemoni päivittelee asennettuja snap-paketteja silloin kun siitä on eniten haittaa, paitsi jos se on toivottua.

Älkää käsittäkö väärin, pidän Ubuntusta paljon (palvelimena), mutta nyt on tässä suht lähiaikoina alkanyt vituttamaan nuo yllämainitut ongelmat, joita ei ollut silloin kun tämän Kubuntun asensin tähän koneeseen... Niin onko tämä vain Kubuntun ongelma, vai Ubuntun ongelma yleisesti?

No, pitäväthän jotkut (kuulemma) turreistakin. Ubuntu on vähän saman asteinen perversio, varsinkin LTS. Mutta jos yhtään lohduttaa niin et ole ongelmasi kanssa yksin: How do I permenently set Firefox snap as default browser?
 
Onko näin, että (K)Ubuntussa (22.04 LTS) ei saa esiasennettua Firefoxia asetettua oletusselaimeksi vastaamalla "Allow" ja "Yes" ainakun sitä kysytään? Ja eikö tosiaankaan esiasennettu Firefox (ilmeisesti snap-paketti) päivity kun vedän onelinerin: sudo apt update && sudo apt upgrade && sudo apt dist-upgrade? On pakko päivittää FF erikseen komennolla sudo snap refresh firefox?

Mitä v...ua?

Älkää käsittäkö väärin, pidän Ubuntusta paljon (palvelimena), mutta nyt on tässä suht lähiaikoina alkanyt vituttamaan nuo yllämainitut ongelmat, joita ei ollut silloin kun tämän Kubuntun asensin tähän koneeseen... Niin onko tämä vain Kubuntun ongelma, vai Ubuntun ongelma yleisesti?
En Ubuntussa firefoxia käytä että oletusselaimesta en osaa sanoa mutta kyllä se näyttää päivittyvän samalla kun ubuntu muutenkin
 
Jos snapcrapit ärsyttää niin Linux Mint (ubuntupohjainen) on ottanut tiukan linjan ja poistanut sen käytöstä. Lisäksi nykyään tekevät itse Firefoxista päivittyvää deb-pakettia (itse käytän kylläkin Vivaldia (vanhan kunnon Operan tekijältä) kun se on ainoa selain jota ei "tyhmennetä" koko ajan vaan tulee uusia toimintoja jatkuvasti, mistä seuraa myös sellainen hyvä sivuvaikutus, että joutuu käyttämään vain ihan muutamaa addonia (bitwarden, cookie autodelete, ublock origin). Suosittelen.
 
Onko foorumilla SSH Public Key Authenticationista kokemusta?

Minulla on ihan mystinen ongelma. Sisäverkossa kaksi Linux-konetta, loin ensimmäiseen avainparin ja lisäsin luodun Public Keyn authorized_keys tiedostoon. Tsekkasin .ssh kansion ja allaolevien tiedostojen oikeudet kuntoon, käynnistin sshd:n uudestaan ja homma toimi.

Mutta toisen koneen kohdalla ei toimikkaan. Kokeilin alkuun tehdä uuden avainparin ja toistaa ylläolevan prosessin, ei toiminut. Ajattelin, että sössin jotain avainparia luodessa ja käytin testiksi tuota toimivaksi todettua edellisen koneen kanssa, ei toimi. Kokeilin luoda kertaalleen vielä uuden avainparin, ei toimi.

sshd_config on kaikilta oleellisilta osilta identtinen (ensimmäisestä koneesta poistin PasswordAuthenticationin käytöstä, kun en sitä enää halua käyttää), käyttisversio on täysin sama (Ubuntu 20.04.4). Virheilmoitukseksi tulee aina vaan alla oleva:
Koodi:
ssh debug1: read_passphrase: can't open /dev/tty: No such file or directory

Minun silmään näyttää oikeuksiin liittyvältä ongelmalta, mutta jos vertaan ls -la komennolla noiden kansioiden oikeudet koneiden välillä, ne ovat täysin identtiset.

Ideoita?

E: Pari tuntia kaivamista ja etsimistä ja kyllä sieltä vaan löytyi yksi kansio, jossa oikeudet olivat väärin ja aiheuttivat ongelman. Nyt Public Keyt toimivat taas. Jos sitä joskus oppisi elämään näiden oikeuksien kanssa ja vaan jaksaisi lukea jokaisen kansion oikeudet huolella...
 
Viimeksi muokattu:
.ssh kansion oikeudet pitää olla 600 tai ssh ei suostu avaamaan avaimia sieltä. Se on itsellä ainakin aihauttanut vastaavan tilanteen.
 
.ssh kansion oikeudet pitää olla 600 tai ssh ei suostu avaamaan avaimia sieltä. Se on itsellä ainakin aihauttanut vastaavan tilanteen.

Oikeat oikeudet on .ssh hakemistolle 700 ja privaattiavaimelle 600. Jos .ssh hakemistolle laittaa 600 niin mikään tiedosto sen alta ei aukea vaikka niissä olisi oikeudet kunnossa koska execute bitti puuttuu. Samoin vastaanottavassa päässä authorized_keys tiedosto pitää olla 600.
 
En Ubuntussa firefoxia käytä että oletusselaimesta en osaa sanoa mutta kyllä se näyttää päivittyvän samalla kun ubuntu muutenkin

Nyt on pari viimeisintä versiota tullut vain kun on erikseen käyny komentamassa
Koodi:
sudo snap refresh firefox
. Aikaisemmin en muista, että tuota ois pitäny tehdä. Outoa...
 
Jos snapcrapit ärsyttää niin Linux Mint (ubuntupohjainen) on ottanut tiukan linjan ja poistanut sen käytöstä. Lisäksi nykyään tekevät itse Firefoxista päivittyvää deb-pakettia (itse käytän kylläkin Vivaldia (vanhan kunnon Operan tekijältä) kun se on ainoa selain jota ei "tyhmennetä" koko ajan vaan tulee uusia toimintoja jatkuvasti, mistä seuraa myös sellainen hyvä sivuvaikutus, että joutuu käyttämään vain ihan muutamaa addonia (bitwarden, cookie autodelete, ublock origin). Suosittelen.

Itellä ei oo mitään Firefoxia vastaan, vaan pidän selaimesta paljon. Pitää tutkia tuo löytyykö Ubuntullekin deb-versio FF:stä.
 
Oikeat oikeudet on .ssh hakemistolle 700 ja privaattiavaimelle 600. Jos .ssh hakemistolle laittaa 600 niin mikään tiedosto sen alta ei aukea vaikka niissä olisi oikeudet kunnossa koska execute bitti puuttuu. Samoin vastaanottavassa päässä authorized_keys tiedosto pitää olla 600.
Näinhän se oli! En tarkistanut, vaan kommentoin muistista. Kiitos korjauksesta.
 
Mintin käyttäjille: eilisen ja tämänpäivän aikana tullut päivitykset itse update manageriin (mintupdate) ja nyt tänään tuon toisen jälkeen siitä softasta on mennyt pakettien autopäivitys päälle itsekseen.. tai ainakin heti alle minuutin päästä sen päivityksen jälkeen on automaattisesti taustalla päivittänyt paketteja! Ihmettelin kun katosi kernel päivitys siitä listalta (huono aika päivittää, ei voi bootata) ja huomasin tuon pakettien autopäivityksen menneen päälle asetuksista (spices ja flatpak autopäivitykset pysyivät pois päältä). Ja kirsikkana kakun päälle, meni tuo paske nyt asentamaan jopa blacklistaamani nvidian ajuriversion. Nyt sitten pitää googlata ja säätää, että saa takaisin vanhemman version takaisin joka toimii parhaiten (kellään nopeaa vinkkiä?). Huoh. Ei ole mintti mitään tällaista perseilyä aiemmin tehnyt.
 
Pitäisi olla korjattuna mintupdate 5.8.4 versiossa joka on just julkaistu. Mutta jos kerkesitte päivittää 5.8.3:seen niin käykää laittamassa pakettien autopäivitykset pois päältä asetuksista (jos siis haluatte manuaalisesti päivittää paketteja).
 
Onko kellään mitään tietoa tästä? Googletuksella saa vähän epämääräisen kuvan/eriäviä selostuksia mitä tuo tekee.
Historialliset syyt nimenomaan. Ei tarvi välittää noista jos et esim. aja japanilaista softaa winen avulla. Vaikuttaa siihen miten terminaali tulkitsee eri merkistöjä. UTF-8 on se jota haluat käyttää. Tietokannoissa (esimerkkinä mariadb) latin1_swedish_ci (collation) tai utf8mb4 on aika turvallinen merkistökoodaus.
 
Viimeksi muokattu:
Olen nyt Nginx:ää säätäessäni saanut jotenkin koneeni resolvconfin (tai jotain muuta) menemään kai sekaisin.

Säädin Nginx:llä Let's Enrypt sertifikaatit paikallisille sisäverkon palveluille. Nyt kun kurkkasin routerin DNS-logeja niin huomasin, että palvelin soittelee muutamaan vanhaan subdomainiin muutaman sekunnin välein. Vanhat subdomainit ovat peruja siitä, kun aiemmin tein itse sertifikaatit sisäverkkoon. Mikään noissa muutaman subdomainin palveluissa ei enää viittaa noihin vanhoihin osoitteisiin. Vanhat sertifikaatit olen mielestäni kaikkialta jo siivonnut ja mielestäni mikään ei niitä edes käytä. DNS tarjoilee näille tietenkin NXDOMAIN-vastausta, mutta olisi kiva saada tuo järkyttävä spämmi DNS:lle loppumaan.

Mistä tätä kannattaisi lähteä avaamaan?

E: Jälleen korjattu, kun vaan etsi tarpeeksi pitkään. Löysin palvelun joka noihin vanhoihin domaineihin soitteli.
 
Viimeksi muokattu:
Heippa linux-hemmot! Onko /var/tmp turvallista laittaa kokonaan excludeen Timeshiftin snapshoteista? Ihmettelin kun tyhjän tilan määrä tipahti kummallisesti. Syypääksi osoittautui Audacityn tmp-tiedostot (~30GB) jotka menivät Timeshiftin snapshottiin. Tuolla var-tempissä näyttäisi olevan vain tuo ja jotain flatpak cachea.

Luulisin, että olisi turvallista laitta excludeen mutta ajattelin varmistaa kerta linux mintin tiimi ei ole sitä defaulttina lisännyt Timeshiftiin vaikka paljon muuta siellä exclude-listalla on, myös jotain var-kansiosta, mutta ei tuota tmp-kansiota.
 
Heippa linux-hemmot! Onko /var/tmp turvallista laittaa kokonaan excludeen Timeshiftin snapshoteista? Ihmettelin kun tyhjän tilan määrä tipahti kummallisesti. Syypääksi osoittautui Audacityn tmp-tiedostot (~30GB) jotka menivät Timeshiftin snapshottiin. Tuolla var-tempissä näyttäisi olevan vain tuo ja jotain flatpak cachea.

Luulisin, että olisi turvallista laitta excludeen mutta ajattelin varmistaa kerta linux mintin tiimi ei ole sitä defaulttina lisännyt Timeshiftiin vaikka paljon muuta siellä exclude-listalla on, myös jotain var-kansiosta, mutta ei tuota tmp-kansiota.

Mielestäni Linuxissa tmp sisältöä, oli se /tmp taikka /var/tmp tulee käsitellä niin että niiden sisältöä ei esim. bootin jälkeen enää ole. Mikäli joku softa ei tykkää siitä että sen jotain sontaa ei sieltä seuraavassa bootissa löydy, niin se ohjelma on silloin rikki.
Eli kyllä voit huoletta laittaa excludeen /tmp ja /var/tmp

Esim. monet distrot nykyään käyttää /tmp hakemistossa tmpfs mounttia, eli se mountataan rammiin. Tästä syystä KANNATTAA olla myös jonkinkokoinen swappi käytössä, koska silloin jos joku softa sattuu kovasti tykittämään tmp ryönää niin se menee automaattisesti swappiin eikä pysyvästi syö muistia.
 
Mielestäni Linuxissa tmp sisältöä, oli se /tmp taikka /var/tmp tulee käsitellä niin että niiden sisältöä ei esim. bootin jälkeen enää ole. Mikäli joku softa ei tykkää siitä että sen jotain sontaa ei sieltä seuraavassa bootissa löydy, niin se ohjelma on silloin rikki.
Eli kyllä voit huoletta laittaa excludeen /tmp ja /var/tmp

On noissa se ero että /var/tmp:n sisältö FHS speksin (5.15. /var/tmp : Temporary files preserved between system reboots) mukaan pitäisi säilyttää boottien yli.
 
Joo mutta se on silti tmp eli ei mitään elintärkeää pitäisi sieltä löytyä. Korkeintaan jotain cacheja jotka voidaan luoda uudelleen mikäli ne puuttuu.
Saattaisikohan olla niin, että jos tuota tmp-kansiota ei otettaisi snapshottiin niin saattaisi tulla joku konflikti jos joku palauttaisi snapshotin jossa flatpakit muuttuisivat mutta tuolla tmp:ssä olevat flatpak cachet eivät? No, täytyy laittaa tuo pelkkä audacityn tmp-kansio excludeen (käyttää kyllä ihan tajuttomasti tilaa kun vähän editoi jotain äänitiedostoa).
 
Saattaisikohan olla niin, että jos tuota tmp-kansiota ei otettaisi snapshottiin niin saattaisi tulla joku konflikti jos joku palauttaisi snapshotin jossa flatpakit muuttuisivat mutta tuolla tmp:ssä olevat flatpak cachet eivät? No, täytyy laittaa tuo pelkkä audacityn tmp-kansio excludeen (käyttää kyllä ihan tajuttomasti tilaa kun vähän editoi jotain äänitiedostoa).

Kaiken järjen mukaan ei. Tietyissä tilanteissa ihan ok säilöä väliaikaisia tiedostoja bootinkin yli jos se esim. nopeuttaa softan käynnistystä, kun ei tarvitse generoida uudestaan. Jos taas softa säilöö jotain oikeasti toiminnan kannalta tarpeellista temppidirrikassa niin se on jo surullista.
 
Saattaisikohan olla niin, että jos tuota tmp-kansiota ei otettaisi snapshottiin niin saattaisi tulla joku konflikti jos joku palauttaisi snapshotin jossa flatpakit muuttuisivat mutta tuolla tmp:ssä olevat flatpak cachet eivät? No, täytyy laittaa tuo pelkkä audacityn tmp-kansio excludeen (käyttää kyllä ihan tajuttomasti tilaa kun vähän editoi jotain äänitiedostoa).

Tuolle /tmp:n sisällön säilymiselle ei anneta mitään takeita, FHS speksaa jopa että sen ei taata säilyvän edes peräkkäisten ohjelman ajokertojen välillä.

Ja kuten mainittu, on usein tmpfs mounttina RAM-muistissa, joten sille voidaan ajella
jotain tmpreaperin tapaista joka tyhjää sitä milloin tahansa tarvittaessa. Joten jos softa laittaa sinne toimintansa kannalta olennaista, oli sitten flatpak tai ei, niin katselisin jotakin toista softaa.

Vaikka /var/tmp:lle lupaillaankin säilymistä boottien yli ja suositellaan siivottavaksi vähemmän aggressiivisesti, niin ei sinnekään mitään kriittistä ole järkevä laittaa.
 
FLATPAK_SYSTEM_CACHE_DIR
The location where temporary child repositories will be created during pulls into the system-wide installation. If this is not set, a directory in /var/tmp/ is used. This is useful because it is more likely to be on the same filesystem as the system repository (thus increasing the chances for e.g. reflink copying), and we can avoid filling the user's home directory with temporary data.

Githubissa joku 5 vuotta auki ollut issue noista flatpak cacheista kun eivät aina siivoudu automaattisesti.
 
Githubissa joku 5 vuotta auki ollut issue noista flatpak cacheista kun eivät aina siivoudu automaattisesti.

Harmillisesti ei käy ilmi koskeeko tuo flatpakia yleisesti, vaiko joillakin tietyillä distroilla tai erityisiä käyttötapauksia. Luulisi että sille olisi tehty jotakin jos se olisi yleisempikin ongelma.

Ainakin systemd pohjaisissa distroissa todennäköisesti käytetään systemd-tmpfilesiä temppihakemistojen hanskaukseen ilman erillisiä tmpreapereita tai vastaavia.

Siinä näyttäisi oletuksna olevan /var/tmp konfiguroitu siivottavaksi 30 päivää vanhemmasta tauhkasta (pl. abrt ja systemd:n private tmpit). Ellei siis tuota ole jotenkin konfiguroitu eri tavalla distrossa tai flatpak käy käpistelemässä vanhojakin cachejaan tämän tästä, ettei noin pääsisi silloin käymään.


Mutta jos flatpak käyttää tuota oikein pelkkänä cachena uusien imagejen hakemisessa niin ei pitäisi olla ongelmaa vaikka snapshotista se puuttuisikin kokonaan. Jos on niin flatpak lienee rikki tältä(kin?) osin.
 
Mutta jos flatpak käyttää tuota oikein pelkkänä cachena uusien imagejen hakemisessa niin ei pitäisi olla ongelmaa vaikka snapshotista se puuttuisikin kokonaan. Jos on niin flatpak lienee rikki tältä(kin?) osin.
Jep. Pitää laittaa nuokin excludeen. Ja lisäksi vielä ajastus noiden poistamiseen, pitää vain varmistaa, että flatpak ei ole ajossa samaan aikaan kuten tuolla issuessakin varoitettiin.
 
Jep. Pitää laittaa nuokin excludeen. Ja lisäksi vielä ajastus noiden poistamiseen, pitää vain varmistaa, että flatpak ei ole ajossa samaan aikaan kuten tuolla issuessakin varoitettiin.

Tuostahan voisi myös katsoa onko se temppfilejen siivous konffattu järkevästi distrossa. Jos siinä ei ongelmaa mutta siivousväli liian pitkä niin noillehan voi lisätä oman säännön lyhyemmällä ajalla. Toki voi myös tutkiskella sen cachen sisältöä että onko siellä vanhallakin roinalla mtime, atime tai ctime suhteellisen tuore joka voisi hämätä tuon ikään perustuvan siivoamisen. Lisäksi ainakin systemd-tmpfiles mahdollistaa tuon vanhenemisen määritykseen käytettävän timestampin valinnan.

Riippuu toki mielenkiinnon ja viitsimisen asteesta, noin itse lähtisin sipulia kuorimaan pääasiassa siksi että minulle tulee sankkeri tämänkaltaisista synkistä häkeistä ja välttelisin mikäli mahdollista.
 
Tuostahan voisi myös katsoa onko se temppfilejen siivous konffattu järkevästi distrossa. Jos siinä ei ongelmaa mutta siivousväli liian pitkä niin noillehan voi lisätä oman säännön lyhyemmällä ajalla.
En jaksa noin syvälle sukeltaa kyllä nyt. EDIT: En oikein tietäisi mistä aloittaa.. toki jonkun journalctl:n koon osaan katsoa (1.1GB näyttäisi olevan). Ainoastaan yhdessä flatpak-cache-kansiossa oli tavaraa n. 4GB verran ja tiedostot näytti olevan helmikuun tienoilta. Eli ei taida mitään distron autosiivousta olla ainakaan noihin. Laitan siivouksen samaan omaan skriptiini jolla hallinnoin flatpak päivityksiä (osa automaattisesti, osasta vain ilmoitukset, jne.), se riittää mulle tällä kertaa.

EDIT2: Se olikin viesti nro 2000.. paljon on aikaa täälläkin tullut vietettyä. :)
 
Heips taas. Kirjoittelin tänne hiljattain locale-asioista ja tarkemmin LC_COLLATE:n muuttamisesta. Tein silloin muutoksen komennolla sudo update-locale LC_COLLATE=fi_FI.UTF-8 ja boottauksen jälkeen kaikki näytti olevan ok. Nyt eilen huomasin, että tiedostosorttaus näytti taas ääkköset ennen a:ta ja vilkaisu locale-komennolla paljasti, että LC_COLLATE on automaattisesti mennyt jossain vaiheessa takaisin "en_US.UTF-8"-arvoksi.

Milläs saan tuon varmasti pysyväksi? Lisäämällä jotain ~/.bashrc-tiedostoon?
 
Heips taas. Kirjoittelin tänne hiljattain locale-asioista ja tarkemmin LC_COLLATE:n muuttamisesta. Tein silloin muutoksen komennolla sudo update-locale LC_COLLATE=fi_FI.UTF-8 ja boottauksen jälkeen kaikki näytti olevan ok. Nyt eilen huomasin, että tiedostosorttaus näytti taas ääkköset ennen a:ta ja vilkaisu locale-komennolla paljasti, että LC_COLLATE on automaattisesti mennyt jossain vaiheessa takaisin "en_US.UTF-8"-arvoksi.

Milläs saan tuon varmasti pysyväksi? Lisäämällä jotain ~/.bashrc-tiedostoon?
Pistä /etc/locale.conf tai /etc/default/locale tuo LC_COLLATE=fi_FI.UTF-8 ja sitten aja locale-gen (mahdollisesti sudolla)

e: Enpä olekkaan varma onko tuo oikea ratkaisu, pikagooglaus taisi mennä mönkään. Mutta ehkä antaa suuntaa :D
e2: ehkä nyt
e3: Ubuntu/Debian käyttää /etc/default/locale
 
Viimeksi muokattu:
Ja jottei mene pelkästään voittopuoleisesti avun pyytämiseksi tässä ketjussa vierailu, tässä vinkki miten jonkun GUI-softan voi avata niin, että sen ikkunaan tulee fokus ja se laitetaan "always on top" tilaan. Testattu linux mintissä.

Esimerkissä avataan gnome-calculator:

bash -c 'gnome-calculator & PIDVAR=$!; sleep 0.3; WINDOWIDVAR=$( wmctrl -lp | grep $PIDVAR | tail -1 | cut -d " " -f 1 ); wmctrl -i -a "$WINDOWIDVAR"; wmctrl -i -r "$WINDOWIDVAR" -b toggle,above'

Aiemmin käytin vähän yksinkertaisempaa tapaa avata kalkkulaattori "on-top"-tilaan mutta se ei toiminut jos avasi enemmän kuin yhden laskimen, tuo yllä oleva ratkaisu toimii vaikka avaa kuinka monta laskin-ikkunaa. Sen pitäisi myös toimia sellaisten softien kanssa jotka avaavat uuden ikkunan saman PID:llä (esim. mintin tiedostohallintasofta Nemo). Sleep-komennon arvoa saattaa joutua muuttamaan isommaksi jos kone/levy on hitaampi kuin minulla, itsellä toimi 0.2 sekunnin asetus mutta laitoin varmuudeksi pikkaisen isomman tauon, että toimii varmasti omalla koneella. Sleep-komento on tarpeellinen, muuten sitä seuraava komento ei toimi kunnolla ja kaikki loputkin komennot feilaa.

Tuon voi laittaa sitten vaikka näppäimistö-shortcutiksi, esim. jos näppäimistöstä löytyy laskin-nappi.
 
Ja tämän muokkaus jää varmasti pysyväksi, ettei taas revertoidu jossain myöhemmässä vaiheessa kun OS tekee/päivittää jotain?
apt kysyy päivittäessä jos löytää ristiriitoja konffifiluissa ja kysyy kumpi versio pidetään. En kyllä suoriltaan osaa sanoa että koskisiko mikään tuohon filuun vai ei. Voit myös vaihtoehtoisesti laittaa käyttäjäkohtaisesti sen tiedostoon ~/.bash_profile:
Koodi:
LC_COLLATE=fi_FI.UTF-8
export LC_COLLATE
 
Voit myös vaihtoehtoisesti laittaa käyttäjäkohtaisesti sen tiedostoon ~/.bash_profile
Mulla ei tuota löydy. .profile tiedosto löytyy. Siellä sanotaan alussa näin:

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.

Eli varmaankin .profile loppuun mainitsemasi komennot?
 
~/.pam_environment myös löytyy ja siellä on jo:

Koodi:
LC_NUMERIC=fi_FI.UTF-8
LC_TIME=fi_FI.UTF-8
LC_MONETARY=fi_FI.UTF-8
LC_PAPER=fi_FI.UTF-8
LC_IDENTIFICATION=fi_FI.UTF-8
LC_NAME=fi_FI.UTF-8
LC_ADDRESS=fi_FI.UTF-8
LC_TELEPHONE=fi_FI.UTF-8
LC_MEASUREMENT=fi_FI.UTF-8
PAPERSIZE=a4
LANGUAGE=en_US
LANG=en_US.UTF-8

Ihmeen monimutkainen juttu (moneen paikkaan kait voi muuttaa mutta ne saattaa toimia eri tavalla/tilanteissa?) miten tän sais pysyvästi muutettua.
 
Ihmeen monimutkainen juttu (moneen paikkaan kait voi muuttaa mutta ne saattaa toimia eri tavalla/tilanteissa?) miten tän sais pysyvästi muutettua.

Oletko kokeillut vain sudo localectl set-locale LC_COLLATE=fi_FI.UTF-8? Pitää muistaa myös että vaikka järjestelmän localen asettaakin jiiriin niin nuo internetin velhojen shellien profiilien ja rc filejen puukotukset joissakin tilanteissa ylikirjoittaa järjestelmätason asetukset. Luonnollisesti ei välttämättä kaikissa.
 
Oletko kokeillut vain sudo localectl set-locale LC_COLLATE=fi_FI.UTF-8?
En muista nyt enää kokeilinko tuota silloin aiemmin. Täytyy kokeilla (myöhemmin tänään, nyt ei pysty hetkeen boottaamaan). Kyselen vain tarkasti näistä nyt kun aiemmin sudo update-locale LC_COLLATE=fi_FI.UTF-8 ei ollutkaan pysyvä muutos vaikka ensimmäisen bootin jälkeen toimikin.

internetin velhojen shellien profiilien ja rc filejen puukotukset joissakin tilanteissa ylikirjoittaa järjestelmätason asetukset
Joo, tiedossa on, kiitos kuitenkin muistutuksesta. Olen pari muutosta .bashrc:hen tehnyt (terminaalin ikkunoiden titlet muuttanut ja laittanut completion-ignore-case päälle) mutta ne eivät tähän asiaan vaikuta.
 
Olen asentamassa linux mint ja kysyisin tosta nvidian ajureista onko vaikeaa saada ajurit asennettua? korttina 3060
 
Olen asentamassa linux mint ja kysyisin tosta nvidian ajureista onko vaikeaa saada ajurit asennettua? korttina 3060
Eipä ne vaikeita ole, tosin jos on yhtään tuoreemmalla raudalla varustettua konetta niin asentaisin ihan jotain muuta kuin Mint:n.
 
Okei, miksi? prossu ryzen 5 3400g ja gtx 3060
Yksi syy voisi ainakin olla se, että Linux Mint käyttää yleisesti vanhaa kerneliä, johon on käännetty kaikki mahdollinen roska mukaan moduleina. Uudesta raudasta tunnetusti saa enemmän irti uusilla ja/tai optimoiduilla kerneleillä.

Myös softa on käytännössä aina vanhaa Mintissä, mutta tämä nyt ei välttämättä liity mitenkään nopeuteen, mutta yleiseen käyttökokemukseen kylläkin.
 
Yksi syy voisi ainakin olla se, että Linux Mint käyttää yleisesti vanhaa kerneliä, johon on käännetty kaikki mahdollinen roska mukaan moduleina. Uudesta raudasta tunnetusti saa enemmän irti uusilla ja/tai optimoiduilla kerneleillä.

Myös softa on käytännössä aina vanhaa Mintissä, mutta tämä nyt ei välttämättä liity mitenkään nopeuteen, mutta yleiseen käyttökokemukseen kylläkin.
Näyttäisi siltä että uusimmassa Mint 21 versiossa on kyllä kerneliversio 5.15 mikä on aika tuore. Tuo prossu on vuodelta 2019 joten tuskin ainakaan sen kanssa tulee mitään ongelmia.
 

Statistiikka

Viestiketjuista
259 564
Viestejä
4 508 816
Jäsenet
74 436
Uusin jäsen
Syrtsy

Hinta.fi

Back
Ylös Bottom