Linux-kysymyksiä & yleistä keskustelua Linuxista

Eore sanoi:
Muistia ei ollut käytössä lainkaan, swappia ei ollut käytössä
Napsauta laajentaaksesi...
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ä?

Eore sanoi:
kaksi CPU corea oli koko ajan 100% loadissa ja niitä käytti ilmeisesti spotify(asennettu AUR kautta)
Napsauta laajentaaksesi...
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:
TenderBeef sanoi:
Onko kellään mitään tietoa tästä? Googletuksella saa vähän epämääräisen kuvan/eriäviä selostuksia mitä tuo tekee.
Napsauta laajentaaksesi...

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.
 
TenderBeef sanoi:
Onko kellään mitään tietoa tästä? Googletuksella saa vähän epämääräisen kuvan/eriäviä selostuksia mitä tuo tekee.
Napsauta laajentaaksesi...

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?
 
A Lake Elk sanoi:
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?
Napsauta laajentaaksesi...

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.

A Lake Elk sanoi:
Ä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?
Napsauta laajentaaksesi...

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?
 
A Lake Elk sanoi:
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?
Napsauta laajentaaksesi...
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.
 
topiv sanoi:
.ssh kansion oikeudet pitää olla 600 tai ssh ei suostu avaamaan avaimia sieltä. Se on itsellä ainakin aihauttanut vastaavan tilanteen.
Napsauta laajentaaksesi...

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.
 
Emeron sanoi:
En Ubuntussa firefoxia käytä että oletusselaimesta en osaa sanoa mutta kyllä se näyttää päivittyvän samalla kun ubuntu muutenkin
Napsauta laajentaaksesi...

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...
 
TenderBeef sanoi:
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.
Napsauta laajentaaksesi...

Itellä ei oo mitään Firefoxia vastaan, vaan pidän selaimesta paljon. Pitää tutkia tuo löytyykö Ubuntullekin deb-versio FF:stä.
 
dome sanoi:
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.
Napsauta laajentaaksesi...
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).
 
TenderBeef sanoi:
Onko kellään mitään tietoa tästä? Googletuksella saa vähän epämääräisen kuvan/eriäviä selostuksia mitä tuo tekee.
Napsauta laajentaaksesi...
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.
 
TenderBeef sanoi:
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.
Napsauta laajentaaksesi...

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.
 
JiiPee sanoi:
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
Napsauta laajentaaksesi...

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.
 
JiiPee sanoi:
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.
Napsauta laajentaaksesi...
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).
 
TenderBeef sanoi:
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).
Napsauta laajentaaksesi...

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.
 
TenderBeef sanoi:
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).
Napsauta laajentaaksesi...

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.
Napsauta laajentaaksesi...

Githubissa joku 5 vuotta auki ollut issue noista flatpak cacheista kun eivät aina siivoudu automaattisesti.
 
TenderBeef sanoi:
Githubissa joku 5 vuotta auki ollut issue noista flatpak cacheista kun eivät aina siivoudu automaattisesti.
Napsauta laajentaaksesi...

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.
 
Barbarossa sanoi:
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.
Napsauta laajentaaksesi...
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.
 
TenderBeef sanoi:
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.
Napsauta laajentaaksesi...

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.
 
Barbarossa sanoi:
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.
Napsauta laajentaaksesi...
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?
 
TenderBeef sanoi:
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?
Napsauta laajentaaksesi...
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.
 
TenderBeef sanoi:
Ja tämän muokkaus jää varmasti pysyväksi, ettei taas revertoidu jossain myöhemmässä vaiheessa kun OS tekee/päivittää jotain?
Napsauta laajentaaksesi...
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
 
bindi sanoi:
Voit myös vaihtoehtoisesti laittaa käyttäjäkohtaisesti sen tiedostoon ~/.bash_profile
Napsauta laajentaaksesi...
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.
Napsauta laajentaaksesi...

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.
 
TenderBeef sanoi:
Ihmeen monimutkainen juttu (moneen paikkaan kait voi muuttaa mutta ne saattaa toimia eri tavalla/tilanteissa?) miten tän sais pysyvästi muutettua.
Napsauta laajentaaksesi...

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.
 
Barbarossa sanoi:
Oletko kokeillut vain sudo localectl set-locale LC_COLLATE=fi_FI.UTF-8?
Napsauta laajentaaksesi...
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.

Barbarossa sanoi:
internetin velhojen shellien profiilien ja rc filejen puukotukset joissakin tilanteissa ylikirjoittaa järjestelmätason asetukset
Napsauta laajentaaksesi...
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
 
Lager7 sanoi:
Olen asentamassa linux mint ja kysyisin tosta nvidian ajureista onko vaikeaa saada ajurit asennettua? korttina 3060
Napsauta laajentaaksesi...
Eipä ne vaikeita ole, tosin jos on yhtään tuoreemmalla raudalla varustettua konetta niin asentaisin ihan jotain muuta kuin Mint:n.
 
Lager7 sanoi:
Okei, miksi? prossu ryzen 5 3400g ja gtx 3060
Napsauta laajentaaksesi...
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.
 
JRan sanoi:
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.
Napsauta laajentaaksesi...
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.
 
potero sanoi:
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.
Napsauta laajentaaksesi...
Kyllä, mutta jos katsotaan tilannetta Mint 21 tukiajan lopussa 2027, niin 5.15 kerneli ei olekaan enää niin tuore. Tuskin tosiaan yhteensopivuus ongelmia on minkään raudan kanssa, koska Linux Mint käyttäjä saa toki tuen kaikelle mitä kernelistä löytyy. Tällä on toki kääntöpuolensa, koska tämä hidastaa konetta huomattavasti. Myös uudempi rauta (prossu, emolevy, ulkoiset laitteet jne.) hyötyy toki aina eniten kernelin kehityksestä. Uskon, että Ryzen prossut tulevat saamaan huomattavasti enemmän kehittäjien aikaa seuraavan viiden vuoden aikana, kuin vaikka Athlon prossut, vaikka molemmat on tuettuja.
 
Itsellä käytössä Debian/Stable, joka on tunnettu vanhoista sovellusversioista, mutta on myös sen vuoksi erittäin vakaa, niin siihen saa backporttauksen kautta jo 5.18 kernelin. Uusimman kernelin saa siis yleensä muutamien kuukausien viiveellä, mikä on toisaalta ihan hyväkin vakauden kannalta. Ei ole ollut ongelmia uusien rautojen kanssa. Empä usko, että yksikään Debian-jakeluun pohjautuva toinenkaan jakelu tekee tähän suurta poikkeusta (esim. Mint).

Toki optiona on aina asentaa Debian/Unstable (Sid) versio, niin siinä on sitten kaikki huonosti testatut viimeisimmät kotkotukset mukana. Ja sitten on yleensä (ei aina) mahdollisuus käännellä niitä softia itsekin jos jotain puuttuu. Näin saat sitten sen viimeisimmänkin Kernelin vaikka heti. Riippuen tekijästä tässä saattaa joskus olla sitten vähän enempi sitä jumppaa :rofl: ja proprietary softat on sitten pois laskuista.

Itse päädyin aikoinaan Debianiin, koska aika monet muut distrot pohjautuu siihen. Eikä syyttä ;) Eikä tuo jakelu ole Phoronixin nopeustesteissäkään ihan huonosti pärjäillyt. Sanoisin, että oikein hyvä Daily Driver käyttis. Dokumentaatio ja muu sosiaalisen median tukihan on myös erittäin kattava.

Asennuksen jms. käytön helppoudesta en sitten lähde analysoimaan, kun itsellä on tuota Linux-taustaa jo 90-luvun puolelta lähtien (=paatunut CLI-henkilö), niin saatan nähdä ja kokea asioita vähän eri valossa, kuin ehkä joku tuoreempi tapaus... ATK-neitsyyskin meni jo 80-luvun alussa.
 
Viimeksi muokattu:
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
266 961
Viestejä
4 619 797
Jäsenet
75 943
Uusin jäsen
1lar1

Hinta.fi

Back
Ylös Bottom