Linux-kysymyksiä & yleistä keskustelua Linuxista

Minun on vähän hankala nyt pysyä kärryillä ylläolevan vastauksen ydinajatuksen kanssa, mutta koetan silti kommentoida jotain:
On niin paljon erilaisia konffeja koko linuxissa että vaikka selaimista, palomuureista, firejail & apparmorit yms. kaikista sais tiedostoina talteen, on niiden palauttaminen sen verran työlästä että koko imagen palauttaminen kerralla taitaa olla parempi ratkaisu. Tai vaihtoehto b, niin lopettaa se säätäminen ja tyytyä johonkin "tuunaamattomaan" perusympäristöön mitä en vielä halua.

Imagen tekeminen ei palauta yhtään mitään sen enempää kuin tiedostojen kopiointi esim. rsync:llä (tosin en ole varma tarkoititko nyt tätä dd/rsync vertailua vai koko järjestelmän palauittamista ylipäätänsä, onhan se rync:llä tehty kopio myös "image"). Rsync pystyy myös päivittämään varmuuskopion (tai palautuksen) siten ettei kaikkea (muuttumattomia tiedostoja) tarvitse kopioida uudelleen. Dd:lle on silti käyttötarkoituksensa ja voihan se joskus (harvemmin) olla hyvä varmuuskopiovälineenäkin (jokin thin client, esim. HTPC, sääasema tms., varsinkin ei-UEFI tai Legacy BIOS-alustat joiden boottisetup eri partitioneen voi olla hyvinkin aikaavievää), mutta harvemmin x86 työpöytäkoneen varmuuskopiointiin järkevä vaihtoehto. On siinä ainakin semmoinen hyvä puoli, että se on paljon yksinkertaisempi oppia käyttämään, mutta rsync:n opettelua varten joutuu lukemaan n 30 minuuttia esim. Archin wikistä käyttövinkkejä sopivan skriptin tekemistä varten.

Asetustiedostoja ei pitäisi olla hirveän monessa paikassa tyypillisessä Linux-järjestelmässä, vaikka käyttötarkoitus olisikin hyvin spesiaali (jos on, niin kannattaa miettiä tekeekö jotain väärin / olisiko fiksumpi ratkaisu). Mutta toisaalta Linuxeja voi käyttää ihan helkatin monella eri tavalla. Ihan varmasti voi olla jokin sellainenkin käyttötapa, että joutuu puukottelemaan sieltä sun täältä järjestelmää käsin ja koko järjestelmän varmuuskopiointi/palautus tarvittaessa voi olla järkevää. Lisäksi, distron asennusohjelma (paketinhallinta) hakee jokaisen paketin ja purkaa ne erikseen uudelleenasennuksessa, mikä on jkv hitaahko prosessi. Koko järjestelmän palautus (rsync-varmuuskopioista tai jopa dd:llä) voi olla huomattavasti nopeampaa kuin uudelleenasennus ja asetustiedostojen palautus, varsinkin jos se on kohtuu tuore.

Pointti siis, mitään yleispätevää ohjetta ei voi antaa oikean työkalun tai toimintatavan valintaan. Itse kukin valitsee omaan käyttötarkoitukseen parhaimman. Nämä keskustelut on kuitenkin tarkoitettu vinkeiksi.

Jos pari kertaa vuodessa muistais imagen luoda niin saattaa selvitä suht.vähällä säätämisellä?

Mitään yleispätevää sääntöä varmuuskoioiden tekemisen tiheydelle on käytännössä hankalaa antaa, käyttötarpeita ja tapoja on niin helkkaristi. Ts. jokainen tekee tyylillään, mutta koska varmuuskopioiden tekeminen on tylsää, kannattaa harkita tämän automatisoimista ainakin osittain (muuten jää helposti tekemättä =) ). Itse ajattelen myös dataa vähän kerroksina, joistain asioista haluaa varmuuskopiot tiheästi esim. fat fingers tms. -virheitä varten tavalla X (snapshottaava tiedostojärjestelmä!), työn alla olevat asiat myös pilveen / git-repoon / rsync:llä tms. netin yli, joistain tiedostoista (esim. asetustiedostot) keskipitkällä tavalla Y, ja joistain (koko järjestelmästä?) hyvin harvoin (esim. 1x/6kk) tavalla Z.

Jos varmuuskopion koon pitää pienenä, on automatisoinnille helpompaa / käytännöllisempää ja halvempaa löytää paikka esim. netin yli (pilvestä, toiselta palvelimelta / koneelta...).
 
On niin paljon erilaisia konffeja koko linuxissa että vaikka selaimista, palomuureista, firejail & apparmorit yms. kaikista sais tiedostoina talteen, on niiden palauttaminen sen verran työlästä että koko imagen palauttaminen kerralla taitaa olla parempi ratkaisu. Tai vaihtoehto b, niin lopettaa se säätäminen ja tyytyä johonkin "tuunaamattomaan" perusympäristöön mitä en vielä halua.

On käyttötiedostoista siis kuitenkin ne backupit tietenkin on myös olemassa. Ja vaikka imagen palauttamisen yhteydessä joutuis jonkun verran säätämäänkin grubia tai muuta taitaa se nopeampaa silti olla käyttövalmiina kuin nykytavalla. Distroina yleensä on jatkuvasti päivittyvät joten ei pitäis hirveästi säätämistä olla. Jos pari kertaa vuodessa muistais imagen luoda niin saattaa selvitä suht.vähällä säätämisellä?

Yleensä käyttöjärjestelmät desktopille ovat melko valmiita että ei minuuttia kauempaa tarvitse kliksutella ja sillä sitten menee vuosia. Mutta jos menee jatkuvasti päivittyvällä tai sellaisella joka päivittyy pari kertaa vuodessa, eli näitä kehittäjille suunnattuja tuoretta tekniikkaa niin voi olla harmeja tiedossa jos enemmänkin säätää kun tietenkin ohjelmissa voi ominaisuudet muuttua. Oletus on se, että siellä ei ole mitään migraatiota ohjelmoitu versioiden välille jos jossain muutoksia, että sitten pitää varustautua korjailemaan jos vanhat konffit ei pelaa. Palvelimessa sitten on omat niksit millä automatisoidaan asioita.

Itse desktopilla tosiaankin asennan vaan tikulta uuden, teen pienet muutokset ja muutan jos tarvetta tulee enkä tee yhtään mitään backuppia järjestelmälle. Ainoastaan kotikansion tiedostot talteen. Jos kiintolevy paukahtaa niin ihan sama, uuden käyttöjärjestelmän asentaa tuoreesta asennusimagesta kuitenkin nopeasti.
 
Viimeksi muokattu:
Pitäisi jaksaa tutustua noihin immutable jakeluihin, että miten toimivat ja miten vaikeaa niiden ylläpito on. Olisiko tuollaisesta vaikka peruskäyttäjälle hyötyä, koska ei voi pistää sekaisin ainakaan helposti.

Tällä hetkellä OpenSuSe Tumbleweed aktiivikäytössä ja siinä tuo Snapper, joka hyödyntää Btrfs on kyllä kätevä, ku voi roll back vetästä milloin vaan, jos vaikka päivitys menee persiilleen, niin bootin jälkeen takas edelliseen tilaan. Tämähän ei tietenkään auta, jos vaikka levy hajoaa, sitä varten on sitten oltava oikeat varmuuskopiot...
 
Minun on vähän hankala nyt pysyä kärryillä ylläolevan vastauksen ydinajatuksen kanssa, mutta koetan silti kommentoida jotain:


Imagen tekeminen ei palauta yhtään mitään sen enempää kuin tiedostojen kopiointi esim. rsync:llä (tosin en ole varma tarkoititko nyt tätä dd/rsync vertailua vai koko järjestelmän palauittamista ylipäätänsä, onhan se rync:llä tehty kopio myös "image"). Rsync pystyy myös päivittämään varmuuskopion (tai palautuksen) siten ettei kaikkea (muuttumattomia tiedostoja) tarvitse kopioida uudelleen. Dd:lle on silti käyttötarkoituksensa ja voihan se joskus (harvemmin) olla hyvä varmuuskopiovälineenäkin (jokin thin client, esim. HTPC, sääasema tms., varsinkin ei-UEFI tai Legacy BIOS-alustat joiden boottisetup eri partitioneen voi olla hyvinkin aikaavievää), mutta harvemmin x86 työpöytäkoneen varmuuskopiointiin järkevä vaihtoehto. On siinä ainakin semmoinen hyvä puoli, että se on paljon yksinkertaisempi oppia käyttämään, mutta rsync:n opettelua varten joutuu lukemaan n 30 minuuttia esim. Archin wikistä käyttövinkkejä sopivan skriptin tekemistä varten.

Asetustiedostoja ei pitäisi olla hirveän monessa paikassa tyypillisessä Linux-järjestelmässä, vaikka käyttötarkoitus olisikin hyvin spesiaali (jos on, niin kannattaa miettiä tekeekö jotain väärin / olisiko fiksumpi ratkaisu). Mutta toisaalta Linuxeja voi käyttää ihan helkatin monella eri tavalla. Ihan varmasti voi olla jokin sellainenkin käyttötapa, että joutuu puukottelemaan sieltä sun täältä järjestelmää käsin ja koko järjestelmän varmuuskopiointi/palautus tarvittaessa voi olla järkevää. Lisäksi, distron asennusohjelma (paketinhallinta) hakee jokaisen paketin ja purkaa ne erikseen uudelleenasennuksessa, mikä on jkv hitaahko prosessi. Koko järjestelmän palautus (rsync-varmuuskopioista tai jopa dd:llä) voi olla huomattavasti nopeampaa kuin uudelleenasennus ja asetustiedostojen palautus, varsinkin jos se on kohtuu tuore.

Pointti siis, mitään yleispätevää ohjetta ei voi antaa oikean työkalun tai toimintatavan valintaan. Itse kukin valitsee omaan käyttötarkoitukseen parhaimman. Nämä keskustelut on kuitenkin tarkoitettu vinkeiksi.



Mitään yleispätevää sääntöä varmuuskoioiden tekemisen tiheydelle on käytännössä hankalaa antaa, käyttötarpeita ja tapoja on niin helkkaristi. Ts. jokainen tekee tyylillään, mutta koska varmuuskopioiden tekeminen on tylsää, kannattaa harkita tämän automatisoimista ainakin osittain (muuten jää helposti tekemättä =) ). Itse ajattelen myös dataa vähän kerroksina, joistain asioista haluaa varmuuskopiot tiheästi esim. fat fingers tms. -virheitä varten tavalla X (snapshottaava tiedostojärjestelmä!), työn alla olevat asiat myös pilveen / git-repoon / rsync:llä tms. netin yli, joistain tiedostoista (esim. asetustiedostot) keskipitkällä tavalla Y, ja joistain (koko järjestelmästä?) hyvin harvoin (esim. 1x/6kk) tavalla Z.

Jos varmuuskopion koon pitää pienenä, on automatisoinnille helpompaa / käytännöllisempää ja halvempaa löytää paikka esim. netin yli (pilvestä, toiselta palvelimelta / koneelta...).
Sori, oman kirjoituksen ulosanti ei ole parasta mahdollista :)
Yritin kuvailla omia tilanteita ja tarpeita, mutta ehkä meni pieleen.

Ei minulle ole mitään väliä millä sen imagen tekee tai opettelee tekemään. Kaikki keinot oli tervetulleita ideoita. Rescuezilla osui ja uppos hyvin. Rsync on myös kyllä muistiin laitettu. Mitä halvemmaksi tulee niin sen parempi. Tarkoitus oli yrittää vähän helpottaa tätä freshinstallin jälkeista säätämistä kun täytyy selaimien ja sen lisäosien backupit palauttaa. Konffata apparmorit sekä firejailit yms "sadat" pikkujutut. Tässä ei ole mitään varsinaista päämäärää ollu koskaan, tämä on vain kiva harrastus. Kokoajan vastaan tulee uutta. Tulee käytettyä paljon just näitä rolling release distroja.

on hyvää keskustelua. Ihan varmasti nämä hommat pystyisi tekemään paremmallakin tapaa, mutta en ole vielä siinä vaiheessa mielestäni. Pikkuhiljaa. Jotkut asiat täytyy vaan ottaa vähän lievemmällä oppimiskäyrällä.
 
Viimeksi muokattu:
Pitäisi jaksaa tutustua noihin immutable jakeluihin, että miten toimivat ja miten vaikeaa niiden ylläpito on. Olisiko tuollaisesta vaikka peruskäyttäjälle hyötyä, koska ei voi pistää sekaisin ainakaan helposti.

Tällä hetkellä OpenSuSe Tumbleweed aktiivikäytössä ja siinä tuo Snapper, joka hyödyntää Btrfs on kyllä kätevä, ku voi roll back vetästä milloin vaan, jos vaikka päivitys menee persiilleen, niin bootin jälkeen takas edelliseen tilaan. Tämähän ei tietenkään auta, jos vaikka levy hajoaa, sitä varten on sitten oltava oikeat varmuuskopiot...
Mulla on menny niin monet kerran Endeavouros jakelun kanssa hommat pieleen kun tuo jakelu tiputtaa päivityksiä todella tiuhaan ja välillä tuntuu etteivät edes testaa toimivatko ne, kun jää vain mustaan ruutuun oma tietokone. Tää backup image on ollu pitkään mielessä jo mutta nyt vasta sain aikaiseksi kysellä, mutta joskus tästä olis ollu valtava apu monet kerrat :) Nää omat jutut vois varmasti toteuttaa paremminkin, mutta näillä on nyt mentävä. Ehkä tuo rescuezilla tai rsync tulee antamaan isot avustukset. Täytyy vaan riittävän iso ssd vielä tilata ja aika näyttää kokeeko sen sitten tarpeelliseksi vai hankaloittaako entisestään.
 
Dd:n käytöstä varmuuskopioihin - kannattaa ymmärtää miksi se (tai vastaava) saattaa ola huono työkalu, ja valita mieluiten oikea sopivampi työkalu, riippuen siitä mikä on päämäärä. Dd voi olla ihan ok mutta usein ei ole!

Alkuperäinen kysymyshän oli imagen teosta ja siihen tarkoitukseen rsync on kyllä täysin väärä työkalu.
 
Alkuperäinen kysymyshän oli imagen teosta ja siihen tarkoitukseen rsync on kyllä täysin väärä työkalu.
Tuo on totta. Aina ei kuitenkaan ole varma, onko kysymys:
1. Kuinka kopioida image?
vai
2. Kuinka kopioida image (koska haluan varmuuskopioita)?

Molempiin voi vastata vaikka 'dd', mutta jälkimmäisen kanssa pitäisi miettiä onko image todella paras tapa tehdä varmuuskopioita.
 
Riittääkö tuon xz-utils takaportin kanssa etttä sshd on disabloituna kotikoneessa? mutta onko tietoa aiheuttaako tuo takaportti itse jotain muutoksia jossain?

Luin jostain uutisesta että githubin xz kehittäjätilit ois laitettu jäihin, eli eikö siihen ole edes tulossa paikkausta?
xz --version komento näyttää että vielä ois käytössä tästä vanha versio kun en ole kerennyt päivittää, mutta kannattaako edes päivittää kun sitten se päivittää vaan tuohon takaporttiversioon?

Kuitenkin Arch linuxin tiedotteessa kehotetaan päivittämään välittömästi...
TL;DR: Upgrade your systems and container images now!
 
Riittääkö tuon xz-utils takaportin kanssa etttä sshd on disabloituna kotikoneessa?
Eikös se tämän hetken tietämyksellä veivannut itsensä sshd:n kylkeen niin, että hyväksyy tietyllä avaimella komennot pahantahtoiselta hyökkääjältä. Eli sshd:n disablointi riittäisi.
Ei aiheutuisi vaaraa, mutta onko tietoa aiheuttaako tuo takaportti itse jotain muutoksia jossain?
Käsittääkseni ei ole tietoa että aiheuttaisi muita muutoksia, mutta tutkimukset kesken eikä varmuutta että tekeekö muutakin.
Luin jostain uutisesta että githubin xz kehittäjätilit ois laitettu jäihin, eli eikö siihen ole edes tulossa paikkausta?
Github pistänyt jäihin, mutta kehittäjä yhä aktiivisena, ks. XZ Utils backdoor , muun infon seassa suunnitelmaa julkaisusta:
"A clean XZ Utils release version could jump to 5.8.0"
mutta kannattaako edes päivittää kun sitten se päivittää vaan tuohon takaporttiversioon?
Arch Linux - News: The xz package has been backdoored mukaan 5.6.0-1 ja 5.6.1-1 sisältää takaoven, kun taas 5.6.1-2 ei.
 
Eikös se tämän hetken tietämyksellä veivannut itsensä sshd:n kylkeen niin, että hyväksyy tietyllä avaimella komennot pahantahtoiselta hyökkääjältä. Eli sshd:n disablointi riittäisi.
Käsittääkseni ei ole tietoa että aiheuttaisi muita muutoksia, mutta tutkimukset kesken eikä varmuutta että tekeekö muutakin.
Github pistänyt jäihin, mutta kehittäjä yhä aktiivisena, ks. XZ Utils backdoor , muun infon seassa suunnitelmaa julkaisusta:
"A clean XZ Utils release version could jump to 5.8.0"

Arch Linux - News: The xz package has been backdoored mukaan 5.6.0-1 ja 5.6.1-1 sisältää takaoven, kun taas 5.6.1-2 ei.
Kiitos, nyt tuo on aika selvää koko homma.
 
Joidenkin lähteiden mukaan koko takaovi ei edes vaikuttanut Arch käyttäjiin ollenkaan.
 
Joidenkin lähteiden mukaan koko takaovi ei edes vaikuttanut Arch käyttäjiin ollenkaan.

Tämä perustuu (tai perustui) siihen että opensshd ei itsessään linkittele liblzma:an, mutta jotkut distrot käyttävät patchattua opensshd:ta joka linkittää libsystemd:n mukaan ("laiska" keino sd_notifyn käyttämiseksi). Libsystemd taas linkittää liblzma:n jota kautta se päätyisi tällä tavalla patchatulla sshd:llä matkaan.

Kaikki distrot eivät tuota patchia käytä, ilmeisesti Arch on yksi näistä.

Mutta tuo "ei koske Archia" väittämä pätee ainoastaan siinä tapauksessa tuota linkitysketjua sshd:hen ei synny mitään muutakaan reittiä pitkin, minkä yksiselitteinen varmistaminen ei ole aivan kevyesti luvattavissa.

Tästä(kin) syystä nuo sorkitut versiot on varmuuden vuoksi pannassa kaikkialla. Osa, esim. Gentoo, poisti varmuuden vuoksi myös 5.4.x versiot joiden rellipaketit ovat Jia Tanin allekirjoittamia vaikka näihin ei oltu vielä koiruuksia lisäilty.
 
Osaako joku linux velho sanoa, mitä pci express root porttia mun samsungin nvme käyttää? Pitäisi siis biosesta käydä muuttamassa pari asetusta, mutta niin palikka etten ymmärrä, mikä porttia tuo nyt käyttää. Porttei mitä siellä voi muuttaa on 1,7,9-12.

00:00.0 Host bridge: Intel Corporation Device 4617
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=14 <?>

00:02.0 VGA compatible controller: Intel Corporation Alder Lake-N [UHD Graphics] (prog-if 00 [VGA controller])
DeviceName: Onboard - Video
Subsystem: Intel Corporation Alder Lake-N [UHD Graphics]
Flags: bus master, fast devsel, latency 0, IRQ 159
Memory at 6000000000 (64-bit, non-prefetchable) [size=16M]
Memory at 4000000000 (64-bit, prefetchable) [size=256M]
I/O ports at 3000
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: [40] Vendor Specific Information: Len=0c <?>
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [100] Process Address Space ID (PASID)
Capabilities: [200] Address Translation Service (ATS)
Capabilities: [300] Page Request Interface (PRI)
Capabilities: [320] Single Root I/O Virtualization (SR-IOV)
Kernel driver in use: i915
Kernel modules: i915

00:0d.0 USB controller: Intel Corporation Device 464e (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: medium devsel, IRQ 128
Memory at 6001010000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Capabilities: [b0] Vendor Specific Information: Len=00 <?>
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.0 USB controller: Intel Corporation Device 54ed (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, medium devsel, latency 0, IRQ 137
Memory at 6001000000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Capabilities: [b0] Vendor Specific Information: Len=00 <?>
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory: Intel Corporation Device 54ef
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: fast devsel
Memory at 6001020000 (64-bit, non-prefetchable) [disabled] [size=16K]
Memory at 600102a000 (64-bit, non-prefetchable) [disabled] [size=4K]
Capabilities: [80] Power Management version 3

00:15.0 Serial bus controller: Intel Corporation Device 54e8
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at 4017000000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller: Intel Corporation Device 54e9
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 40
Memory at 4017001000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:16.0 Communication controller: Intel Corporation Device 54e0
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 158
Memory at 6001027000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [a4] Vendor Specific Information: Len=14 <?>
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1c.0 PCI bridge: Intel Corporation Device 54be (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 122
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80a00000-80bfffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.0 PCI bridge: Intel Corporation Device 54b0 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 123
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80800000-809fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.1 PCI bridge: Intel Corporation Device 54b1 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 124
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80600000-807fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.2 PCI bridge: Intel Corporation Device 54b2 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 125
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80400000-805fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.3 PCI bridge: Intel Corporation Device 54b3 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 126
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80c00000-80cfffff [size=1M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1e.0 Communication controller: Intel Corporation Device 54a8
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 4017002000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:1e.3 Serial bus controller: Intel Corporation Device 54ab
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 37
Memory at 4017003000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:1f.0 ISA bridge: Intel Corporation Device 5481
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0

00:1f.4 SMBus: Intel Corporation Device 54a3
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: medium devsel, IRQ 16
Memory at 6001024000 (64-bit, non-prefetchable)
I/O ports at efa0
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801

00:1f.5 Serial bus controller: Intel Corporation Device 54a4
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: fast devsel
Memory at 80d00000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: intel-spi
Kernel modules: spi_intel_pci

01:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at 80a00000 (32-bit, non-prefetchable) [size=1M]
Memory at 80b00000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-29
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 80800000 (32-bit, non-prefetchable) [size=1M]
Memory at 80900000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-2a
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at 80600000 (32-bit, non-prefetchable) [size=1M]
Memory at 80700000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-2b
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at 80400000 (32-bit, non-prefetchable) [size=1M]
Memory at 80500000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-2c
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

05:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd SSD 970 EVO
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at 80c00000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [b0] MSI-X: Enable+ Count=33 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [158] Power Budgeting <?>
Capabilities: [168] Secondary PCI Express
Capabilities: [188] Latency Tolerance Reporting
Capabilities: [190] L1 PM Substates
Kernel driver in use: nvme
Kernel modules: nvme

-[0000:00]-+-00.0
+-02.0
+-0d.0
+-14.0
+-14.2
+-15.0
+-15.1
+-16.0
+-1c.0-[01]----00.0
+-1d.0-[02]----00.0
+-1d.1-[03]----00.0
+-1d.2-[04]----00.0
+-1d.3-[05]----00.0
+-1e.0
+-1e.3
+-1f.0
+-1f.4
\-1f.5

PS. Muutin asetuksen jokaisesta pcie root portista niin näyttää toimivan..
 
Viimeksi muokattu:
Onkohan kovin yleistä Linuxissa ettei kaikilla hiirillä kaikki napit toimi? Itsellä Deltacon langaton ja alkuun testaamassani Garudassa näin että peukalon eteen/taakse-nappulat ei tunnistu lainkaan. Unohdin linuxin hetkeksi kunnes innostuin testailemaan taas Minttiä ja siinäkin sama homma. Netin ohjeet neuvoo kalastelemaan terminaalissa inputtipalautteen perusteella nappien numerot ja määrittelemään ne uudelleen conffitiedostoon mutta itsellä nuo napit vaikuttaa olevan täysin pois pelistä eikä minkäänlaista palautetta tule, eli liekö sitten mitään tehtävissä?
 
Onkohan kovin yleistä Linuxissa ettei kaikilla hiirillä kaikki napit toimi? Itsellä Deltacon langaton ja alkuun testaamassani Garudassa näin että peukalon eteen/taakse-nappulat ei tunnistu lainkaan. Unohdin linuxin hetkeksi kunnes innostuin testailemaan taas Minttiä ja siinäkin sama homma. Netin ohjeet neuvoo kalastelemaan terminaalissa inputtipalautteen perusteella nappien numerot ja määrittelemään ne uudelleen conffitiedostoon mutta itsellä nuo napit vaikuttaa olevan täysin pois pelistä eikä minkäänlaista palautetta tule, eli liekö sitten mitään tehtävissä?
Ei tuo ainakaan hirveän yleistä ole kun itselläni on Ubuntu/Xubuntu/Debian -koneissa viimeisten 10v aikana ainakin 6 eri Microsoftin tai Logitechin hiiren sivunapit toimineet ihan suoraan. En sitten tiedä onko tuossa Deltacossa jotenkin epästandardisti tehty nuo sivunapit.
 
Onkohan kovin yleistä Linuxissa ettei kaikilla hiirillä kaikki napit toimi? Itsellä Deltacon langaton ja alkuun testaamassani Garudassa näin että peukalon eteen/taakse-nappulat ei tunnistu lainkaan. Unohdin linuxin hetkeksi kunnes innostuin testailemaan taas Minttiä ja siinäkin sama homma. Netin ohjeet neuvoo kalastelemaan terminaalissa inputtipalautteen perusteella nappien numerot ja määrittelemään ne uudelleen conffitiedostoon mutta itsellä nuo napit vaikuttaa olevan täysin pois pelistä eikä minkäänlaista palautetta tule, eli liekö sitten mitään tehtävissä?

Deltacon kohdalla kyllä, on normaalia, että heidän hiiret ei toimi kunnolla Linuxin kanssa. Noitten halppis pommien kanssa oot ihan oman onnes varassa... Linux nojaa standardeihin, Windows taas nojaa Microsoftiin...
 
Jahas, eli paree ilmeisesti olla sitten laadukas merkkihiiri näiden Linuxien kanssa. Mielenkiintoista sinällään kun Windowsissa käsittääkseni kuitenkin ihan standardiajureilla toimii nämä halppikset eikä niille tarvi mitään omia asennella, että luulisi sitten jonkin sortin standardeja noudattavan mutta ilmeisesti Mikkisoftan standardit ei ole samat kuin Linuxilla sitten.
 
Jahas, eli paree ilmeisesti olla sitten laadukas merkkihiiri näiden Linuxien kanssa. Mielenkiintoista sinällään kun Windowsissa käsittääkseni kuitenkin ihan standardiajureilla toimii nämä halppikset eikä niille tarvi mitään omia asennella, että luulisi sitten jonkin sortin standardeja noudattavan mutta ilmeisesti Mikkisoftan standardit ei ole samat kuin Linuxilla sitten.

Aikoinaan esim. nettisivut piti suunnitella erikseen yhdet sivut Microsoftin Internet Explorerille ja toiset muille selaimille, kun IE noudatti Microsoftin omia "standerdeja". Ja olikohan se PPP-protokolla, josta Microsoft halusi, että se kirjoitettaisiin uudestaan kun heidän toteutus ei toimi muiden kanssa yhteen. Tuolloin prokollan kehittäjän eivät suostuneet asiaan ja jopa Microsoft joutui sillä kertaa taipumaan ja korjaamaan oman toteutuksen standardin mukaiseksi. Ja tuohon vielä asiakirjastandardi kaaos (oliko se nyt odt, joka haluttiin ainoaksi formaatiksi), kun Micosoftille ei kelvannut avoin OpenDocument-formaatti, vaan halusi väkisin oman formaatin rinnalle, joka hoitui hienosti lahjomalla porkukkaa ympärimaailmaa docx-formaatin taakse ja tulos näkyy tänäkin päivänä...

Joten joo heillä on "vähän" erilainen käsitys standardeista...
 
Aikoinaan esim. nettisivut piti suunnitella erikseen yhdet sivut Microsoftin Internet Explorerille ja toiset muille selaimille, kun IE noudatti Microsoftin omia "standerdeja". Ja olikohan se PPP-protokolla, josta Microsoft halusi, että se kirjoitettaisiin uudestaan kun heidän toteutus ei toimi muiden kanssa yhteen. Tuolloin prokollan kehittäjän eivät suostuneet asiaan ja jopa Microsoft joutui sillä kertaa taipumaan ja korjaamaan oman toteutuksen standardin mukaiseksi. Ja tuohon vielä asiakirjastandardi kaaos (oliko se nyt odt, joka haluttiin ainoaksi formaatiksi), kun Micosoftille ei kelvannut avoin OpenDocument-formaatti, vaan halusi väkisin oman formaatin rinnalle, joka hoitui hienosti lahjomalla porkukkaa ympärimaailmaa docx-formaatin taakse ja tulos näkyy tänäkin päivänä...

Joten joo heillä on "vähän" erilainen käsitys standardeista...
Microsoftin vika kun hiiri ei toimi Linuksissa? Vai miten tämä vuodatus tulisi tulkita
 
Tulkitsin avautumisen siten, että isot toimijat, joilla on paljon valtaa (/rahaa), kusee standardien päälle, jos siihen vain on jokin kannustin (vendor-lock-inin mahdollisuus, datan keräys tms.), ja saa valitettavan usein myös tahtonsa läpi.

Hiiristä puheenollen, ei ole vielä koskaan tullut vastaan hiirtä joka ei toimisi standardina HID-hiirenä. Melkeinpä niin päin, että kalliimmissa spesiaalihiirissä joissa on jos jonkinlaista hilavitkutinta ja erikoisominaisuutta, on osa ominaisuuksista saattanut olla jonkin erityisemmän, mutta kuitenkin jonkin kohtuullisen standardin, takana. Osa erikoisnapeista voi ollakin esim. näppäimistö Kernelin mielestä. RGB:kin on yleensä reverse-engineerattu ja saa toimimaan jollain harrasteiljoiden softalla; mutta perushiiirenä (tarkoittaa siis vähintään 5-, usein 7-nappinen osuus) toimii ihan standardiajureilla.

Toki on ihan uskottavaa, että halvimmista halvimmat tietokonehiiret (tai jotkin erät) on tehty jollain mahdollisimman halvalla saaduista ylijäämäosista, jotka ei sitten tuekaan mitään standardia, koska osat on aluperin mihinlie puoliksi suljettuun tarkoitukseen tehty. Siis tarkoitan, että uskon kyllä ylläolevan keskustelun, Deltacon hiiret ei toimi, mutta varmaankin poikkeus?

Noin ihan mielenkiinnosta ja ehkä jopa hyödyllisenä tietona, näkisin miten ko. hiiri näkyy lsusb:n listauksessa (erityisesti valmistajan ja osan id:t kiinnostaa, eli ne xxxx:yyyy -numerosarjat, varsinkin jos niitä on monta) ja mitä xev ja evtest sanoo.

EDIT: Linuxille ei todellakaan tarvitse ostaa kalliimpaa ja erityisen laadukasta hiirtä. Ongelmat näitten kanssa on todella harvinaisia.
 
Viimeksi muokattu:
Pintapuolisesti yksinkertainen asia mutta koska kyseessä USB niin mikään ei olekaan enää yksioikoista jos kurkistaa syvemmälle. Aihe on melko monimutkainen eikä riitä aika tai motivaatio kovin syvällistä tekstiä kirjoittamaan, mutta raapaisen vähän pintaa:

USB HID Class speksin mukaiset hiiret ja näppikset pääsääntöisesti toimivat Linuxissakin ilman ylimääräisiä säätöjä, peliohjaimetkin mutta näiden tukeminen on paljolti pelistä kiinni. Toki täydellistä maailmaa ei olekaan ja kaskessa voi olla monta kantoa, tässä muutama toivottavasti havainnollistava esimerkki osin omien havaintojen pohjalta ja osin speksin rajoissa teoriaa.

Laitevalmistaja voi olla lähtenyt sooloilemaan ja tekee jotakin speksin ulkopuolista, ja vaatii ajurin joka kertoo käyttöjärjestelmälle että mitä se tekee. Yleensä ajuri on tarjolla ainoastaan Windowsille ja ellei valmistaja tiedä mitä tekee, voi olla turhauttava kokemus. Harvinaista näppisten ja hiirten kohdalla, mutta tämä on selkeä tapaus jos sellainen sattuu.

Yleisemmät tapaukset ovat kuitenkin hiukan hankalampia avata. USB HID (kuten useimmat USB luokat) luokka toimii siten että laite itse ilmoittaa isännälle (report descriptor) että mitä sen lähettämät reportit pitävät sisällään, esim. hiiren osoittimet, näppäinpainallukset, analogiohjainten asennot, ym. Ja on laitteen (valmistajan) vastuulla huolehtia että nuo descriptorit ovat järkeviä, ja että ne reportit vastaavat descriptoreita ja ovat myös kuranttia tavaraa. Kuten ylempänä jo sivuttiinkin, yksi fyysinen laite voi ilmoittaa useamman USB laitteen isännälle eikä se ole mahdotonta että vaikka jokin astetta monimutkaisempi peliohjain ilmoittaa olevansa hiiri, näppäimistö ja joystick yhtä aikaa,

Esimerkkinä hiiri. Oikea ja vasen nappi ovat aika lailla pienin yhteinen nimittäjä kaikille, nykyään myös rulla jonka painallus toimii myös keskinappina käytännössä aina. Mutta siitä eteenpäin ollaankin vähän ohuemmilla jäillä. Vaikkapa nykypäivänä ei mitenkään harvinainen hiiri, kolme nappia, rulla ja kaksi peukalonappia. Hiiri voi ilmoittaa yksinkertaisesti että nappeja on viisi, vastaanottajan päätettävissä mitä nelos ja vitosnappi tekee. Tai sitten ne lähettävätkin browser forward/backward näppäinkoodit.

Jos kiinnostaa ryömiä kaninkoloon niin kernelin dokkari Introduction to HID report descriptors — The Linux Kernel documentation lienee hyvä alkupiste.
 
Noin ihan mielenkiinnosta ja ehkä jopa hyödyllisenä tietona, näkisin miten ko. hiiri näkyy lsusb:n listauksessa (erityisesti valmistajan ja osan id:t kiinnostaa, eli ne xxxx:yyyy -numerosarjat, varsinkin jos niitä on monta) ja mitä xev ja evtest sanoo.

Lsusb näyttää

Bus 003 Device 002: ID 0603:0002 Novatek Microelectronics Corp. Sino Wealth keyboard/mouse 2.4 GHz receiver

xev ja evtest ei reagoi mitenkään kun painelen noita eteen/taakse-namiskoja. Muutoin tulee palautetta kaikilta muilta OK. Evtest näytti tällaista

/dev/input/event6: SINO WEALTH USB Composite Device
/dev/input/event7: SINO WEALTH USB Composite Device Mouse
/dev/input/event8: SINO WEALTH USB Composite Device System Control

Vauras on USB laite :lol: Hiiri siis Deltaco MS-776.
 
Mulla on ongelmana, että en saa Rocky Linux 9.2:sta poistettua salasanalla kirjautumista ssh:lla.

# cat /etc/ssh/sshd_config
Koodi:
#    $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# To modify the system-wide sshd configuration, create a  *.conf  file under
#  /etc/ssh/sshd_config.d/  which will be automatically included below
Include /etc/ssh/sshd_config.d/*.conf

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile    .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#KbdInteractiveAuthentication yes
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in RHEL and may cause several
# problems.
#UsePAM no
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server
# cat /etc/ssh/sshd_config.d/04-ipa.conf
Koodi:
# IPA-related configuration changes to sshd_config

PubkeyAuthentication yes
##Lisätty Yubikey autentikointia varten
PubkeyAuthOptions verify-required
KerberosAuthentication no
GSSAPIAuthentication yes
UsePAM yes
ChallengeResponseAuthentication yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Mistä se vielä voi vielä sen kaivaa vielä luvan sille? Ubuntu 22.04 servuissa on toi sama /etc/ssh/sshd_config.d/04-ipa.conf -tiedosto, eikä ne päästä passulla sisään, ainoastaan noi Rockyt ei suostu tottelemaan. Niin joo ja muita conffeja ei tuolla /etc/ssh/sshd_config.d -hakemistossa ole.

Sain tämän viimeinkin ratkaistua, se kun levisi myös Ubuntu Servuihini. Eli ongelmana oli se, että autentikointitavoissa näkyi järkähtämättä "KbdInteractiveAuthentication", vaikka se oli nimenomaan estetty conffeissa, jolloin pääsi kirjautumaan sisään passulla, vaikka sekin oli konffeissa estetty.

Se mikä tuon "KbdInteractiveAuthentication" pakotti päälle on "ChallengeResponseAuthentication yes", sen kun vaihtoi asentoon "ChallengeResponseAuthentication no", niin samalla katosi toi "KbdInteractiveAuthentication" sallituista autentikointi metodeista. PAM:illa ei ollut mitään tekemistä asian kanssa.
 
Mikäs juttu tuossa Ubuntu 24.04:ssa ja ilmeisesti(?) Pipewiressä ilman Pulseaudiota oikeen on, kun ääni kuulostaa ihan siltä kuin se tulisi vanhalta vinyyliltä? Sellasia ihme rusahuksia jatkuvasti. Heti kun asenti Pulse audion niin ongelmat korjaantu.
Edit: vitut se mitään korjannu.
 
Viimeksi muokattu:
Github on muuttunut archived ja read only tilaan ihan hiljattain.

"Neofetch is a CLI system information tool written in BASH. Neofetch
displays information about your system next to an image, your OS logo,
or any ascii file of your choice. "
 

Liitteet

  • neofetch.jpg
    neofetch.jpg
    110,8 KB · Luettu: 60
Lainaan Linux distrokeskustelu -langasta viestin:
Tähän saakka nVidialla on myös koko työpöydän virkistystaajuus sidottu siihen, missä ohjelmassa on matalin virkistystaajuus. Jos joku X11 (Xwayland) CAD softa pyörii 15 fps, silloin koko työpöytä on lukittu 15 Hz, koska nVidian binääriajuri ei tue lainkaan Implicit synciä. Explicit syncin jälkeen tämä(kin) on vihdoin kunnossa Waylandilla.

Linux-aloittelijana kokeilin kuukausi sitten eri distroja, enkä saanut työpöytää yli 60 hz virkistystaajuudelle, vaikka nvidian ajurin onnistuin asentamaan.

Keskustelut tuntuvat pyörivän pelien ympärillä, mutta itselle olisi merkittävämpää saada työpöydälle 144 hz. Ei tarvitse olla edes variable refresh rate. 60 hz tuntuu lagiselta ja tökkivältä, tosin Gnome saattoi muutenkin tuntua hitaalta.

Onko varmin ratkaisu vaihtaa AMD:n näyttikseen? Raudan vaihtaminen on helppoa, kun taas käyttöjärjestelmän kanssa kikkailu tökkii, kun oma ideaali on pidättäytyä pitkälti vanilla-ratkaisussa ja asentaa mahdollisimman vähän mitään.

edit. Tai olisiko peräti Intel Arc -näyttis vielä parempi?
 
Viimeksi muokattu:
Onko varmin ratkaisu vaihtaa AMD:n näyttikseen? Raudan vaihtaminen on helppoa, kun taas käyttöjärjestelmän kanssa kikkailu tökkii, kun oma ideaali on pidättäytyä pitkälti vanilla-ratkaisussa ja asentaa mahdollisimman vähän mitään.

AMD:n näyttisajurit on pitkälti kernelissä suoraan eli mitään binaari ajureita ei AMD:n puolella tartte asennella
 
Lainaan Linux distrokeskustelu -langasta viestin:


Linux-aloittelijana kokeilin kuukausi sitten eri distroja, enkä saanut työpöytää yli 60 hz virkistystaajuudelle, vaikka nvidian ajurin onnistuin asentamaan.

Keskustelut tuntuvat pyörivän pelien ympärillä, mutta itselle olisi merkittävämpää saada työpöydälle 144 hz. Ei tarvitse olla edes variable refresh rate. 60 hz tuntuu lagiselta ja tökkivältä, tosin Gnome saattoi muutenkin tuntua hitaalta.

Onko varmin ratkaisu vaihtaa AMD:n näyttikseen? Raudan vaihtaminen on helppoa, kun taas käyttöjärjestelmän kanssa kikkailu tökkii, kun oma ideaali on pidättäytyä pitkälti vanilla-ratkaisussa ja asentaa mahdollisimman vähän mitään.

edit. Tai olisiko peräti Intel Arc -näyttis vielä parempi?

Sellainen huomio AMD korteista, että 4K@120hz ei toimi 4:4:4 chromalla, mikäli käytössä HDMI.
HDMI 2.1 sisältää suljettua koodia, joten ei toimi täysin AMD:n open source ajureilla.
 
Mikäs juttu tuossa Ubuntu 24.04:ssa ja ilmeisesti(?) Pipewiressä ilman Pulseaudiota oikeen on, kun ääni kuulostaa ihan siltä kuin se tulisi vanhalta vinyyliltä? Sellasia ihme rusahuksia jatkuvasti. Heti kun asenti Pulse audion niin ongelmat korjaantu.
Edit: vitut se mitään korjannu.

Mulla pätki äänet kuorman alla Pipewirellä. Tuolla jotain ohjeita asiaan liittyen: PipeWire - Debian Wiki

Käytännössä tein tiedoston ~/.config/pipewire/pipewire.conf.d/10-choppy-under-load.conf
ja mulla se toimi tällaisella conffilla.
Koodi:
context.properties = {

    default.clock.min-quantum = 1024
    default.clock.quantum = 1024

    default.clock.max-quantum   = 4096
}
 
Mulla pätki äänet kuorman alla Pipewirellä. Tuolla jotain ohjeita asiaan liittyen: PipeWire - Debian Wiki

Käytännössä tein tiedoston ~/.config/pipewire/pipewire.conf.d/10-choppy-under-load.conf
ja mulla se toimi tällaisella conffilla.
Koodi:
context.properties = {

    default.clock.min-quantum = 1024
    default.clock.quantum = 1024

    default.clock.max-quantum   = 4096
}
Varsin erikoinen onglema, kun eilen keskiviikkona ei ollu audiossa mitään ongelmaa, mutta tiistaina rätisi ja poksu ihan jatkuvasti. Minusta ihan sama oliko muuta kuormitusta vai pelkkä selain ja siinä youtube auki niin audio oli ihan hirvee. Testasin myös säätää noita qauntum asetuksia mutta ei niillä ollu mitään vaikutusta oikeastaan ellei kaikkia kolmea arvoa arvolle 32 jolloin äänestä tuli kovin robottimainen. :D
Hyvin mystinen ongelma joka korjaantui nähtävästi itsestään.
Edit: niin ja se ei tosiaan ole varsinaista pätkimistä vaan juurikin äänet kuulostaa siltä kuin tulisi joltain vinyylilevyltä soitettuna.
 
Sellainen huomio AMD korteista, että 4K@120hz ei toimi 4:4:4 chromalla, mikäli käytössä HDMI.
HDMI 2.1 sisältää suljettua koodia, joten ei toimi täysin AMD:n open source ajureilla.

Oho. Tuo koskee ilmeisesti omaa setuppiani, kun käytän ryzenin gpu:ta ja hdmi -> dp muunninta, koska emolevyssä ei ole dp-liitintä eikä näyttö huoli 4k@60hz kuvaa hdmi:n kautta.

En ole kylläkään huomannut mitään, mutta musta teksti valkoisella pohjalla näyttänee ihan samalta pakattunakin.
 
Edit: niin ja se ei tosiaan ole varsinaista pätkimistä vaan juurikin äänet kuulostaa siltä kuin tulisi joltain vinyylilevyltä soitettuna.
Vinyylilevyssä on tosi hyvä soundi!!!! (jos on levyt ja laitteet kunnossa :lol:)

Vakavissaan, oliko toi siis jatkuvaa ritinää vai oliko myös tajuusvasteessa / volyymissä jotain vikaa, vähän tyyliin niin kuin olis RIAA-korjan rikki tms.?

Jos pelkkää rätinää, niin jokin puskurijuttuihan tuo on. Joko puskurin koko laitettu liian tiukille tai sitten ketjussa / äänistackissä joku osa bugittaa ja muodostaa pullonkaulan / ei välitä dataa riittävän nopeasti.

Tosiaan aika omituinen juttu. Itse olen lähinnä Linux-puolella törmännyt tilanteeseen, että on pitänyt säätää puskureita yleensä pienemmälle, jos on pitänyt saada latenssit oikeasti pieniksi. Oletusasetukset tuppaa olemaan konservatiivisia, jotta äänet toimii jokaikisellä perunakoneella oikein ilman isompia pätkimisiä (mutta PulseAudion ja Pipewiren myötä oletuksiakin on pienennetty).
 
Vinyylilevyssä on tosi hyvä soundi!!!! (jos on levyt ja laitteet kunnossa :lol:)

Vakavissaan, oliko toi siis jatkuvaa ritinää vai oliko myös tajuusvasteessa / volyymissä jotain vikaa, vähän tyyliin niin kuin olis RIAA-korjan rikki tms.?

Jos pelkkää rätinää, niin jokin puskurijuttuihan tuo on. Joko puskurin koko laitettu liian tiukille tai sitten ketjussa / äänistackissä joku osa bugittaa ja muodostaa pullonkaulan / ei välitä dataa riittävän nopeasti.

Tosiaan aika omituinen juttu. Itse olen lähinnä Linux-puolella törmännyt tilanteeseen, että on pitänyt säätää puskureita yleensä pienemmälle, jos on pitänyt saada latenssit oikeasti pieniksi. Oletusasetukset tuppaa olemaan konservatiivisia, jotta äänet toimii jokaikisellä perunakoneella oikein ilman isompia pätkimisiä (mutta PulseAudion ja Pipewiren myötä oletuksiakin on pienennetty).
Tämä vinyyli on niitä pykälää huonompia kunnolta ei siis mitään mint kuntoista! ;)
Juurikin sellaista ei täysin jatkuvaa ritinää mutta ritinää kuitenkin (tai ritinää jossa on taukoja jopa minuutteja välissä). Eilen ei tosiaan ollu ongelmaa, mutta tänään taas on ollu. Jotain tekemistä tuolla pipewirellä (ja uusimmalla Ubuntu 24.04 matella) on asian suhteen, kun ei ikinä aikasemmin oo ollu äänien kanssa mitään ongelmia. Tosin aikasemmin on ollu pulseaudiota tai alsaa käytössä pelkästään.
Miltä kuulostaa rikkinäinen RIAA-korjain?
 
EDIT: Linuxille ei todellakaan tarvitse ostaa kalliimpaa ja erityisen laadukasta hiirtä. Ongelmat näitten kanssa on todella harvinaisia.

Sattuipa kyllä lotto kohdalle kun tuossa vakkari-Deltacon hiiressä ei toimi eteen/taakse-napit mutta kun kaivoin kaapin periltä parit langattomat ebayn törkeen halvat kiinanhiiret niin toimi kaikki napit. Onnistuin siis Suomesta ostamaan vielä kiinalaisempaa laatua kuin suoraan Kiinasta. Ainut huono noissa ebay-hiirissä vaan että imevät patterit kolminkertaisella vauhdilla.
 
Miltä kuulostaa rikkinäinen RIAA-korjain?
Itse asiassa kovin montaa rikkinäistä RIAA-korjainta ei ole tullut kuunneltua ;-). Mutta vinyylisoitin (jossa ei ole sisäänrakennettua RIAA:ta) on tullut monta kertaa laitettua line-in:iin.

RIAA voisi mennä rikki monella tapaa (harvoin menee). Voisi olla, että rikkinänen RIAA, kuulostaa vähän samalta kuin levari yhistettynä line inputtiin; eli äänessä on täysin pielessä oleva taajuusvaste tavalla tai toisella, esim. kuuluu pahvilaatikosta, tinapurkista tms.; pointti siis, että se ei lisää ritinöitä. Lähinnä koetin saada tarkempaa kuvausta, mistä vois ehkä päätellä, mikä on tossa Linuxin äänijärjstelmässä/ajurissa/stackissa on rikki.

RIAA-korjainhan tekee käänteisen (RIAA-)muunnoksen taajuusvasteeseen, mikä ääneen on tehty ennen kuin se on kaiverrettu vinyylilevylle. Sillä ei (varsinasesti) ole mitään tekemistä ritinän kanssa, vaan bassot korostetaan ja koko äänen (jännite-)tasoa nostetaan vähän, jotta se voidaan laittaa eteenpäin tavalliselle vahvistimelle (eri asetukset MC- MM-rasioille ja kiteille yms., mutta ei niitä muuntyyppisiä rasioita ole ollut kuin low-end vehkeissä 70-luvulla ja sitä ennen; MM on yleisin ja "tavallinen", jos RIAA-korjaimessa ei ole asetusta tai erikseen mainintaa niin se on MM-rasialle. 2000-luvun jälkeisissä low-end vinyylisoittimissa RIAA-korjain on usein sisäänrakennettu, ja sen tietää siitä että levarin voi yhistää tavallisen vahvistimen line-inputtiin suoraan).

Paitsi, noh, olihan itse asiassa yksi syy RIAA-muunnokselle oli siinä, että pölystä, naarmuista ja prässäysvirheistä johtuvat ritinät on enimmäkseen korkeilla taajuuksilla. Kun tehdään kaiverros suhteellisesti korostamalla korkeita taajuuksia, vaimenee myös ritinät, kun tehdään käänteinen muutos RIAA-korjaimella. Savilevyt ja muut äänitteet, joita tehtiin enne RIAA-järjestelmää (ja vastaavia), rätisivät huomattavasti enemmän. Isompi syy muunokselle on se, että levylle ei ole mahdollista kaivertaa bassotaajuuksia ilman sitä. Jotakuinkin realistiselta kuulostavan äänilevyn tekeminen on mahdotonta ilman RIAA-muunnosta.

 
Viimeksi muokattu:
Ajuri ongelmalta toi ei vaikuta, koska usb-liitäntäisillä kuulokkeilla kuuluu myös tota ritinää ja niillä se on vielä voimakkaampaa, joka johtunee varmaan tausta melun vaimenemisesta.
Jotta helvetin hienosti toimii tämä uusi ja hieno pipewire :smoke:
Toisaalta ihan hyvä kun eivät menneet tota xorgia korvaamaan waylandilla Ubuntu matessa vielä, tiiä mitä ongelmia siitäkin ois syntyny.
 
Mullakin oli jotain ongelmaa Pipewirellä. Aina kun äänen soitto loppui, niin kuului raksahdus. Ongelma loppui, kun heitin Pipewiren veks. Kai senkin olisi saanut jotenkin korjattua, mutta ei mitään hajua miten, ja miksi tuhlata aikaa. Mäkään en ala kokeilemaan Waylandia samasta syystä. Jos KDE nyt sitä edes tuki kunnolla vielä.
 
psmem ohjelma linuxille on tosi näppäri sillä sillä näkee tarkkaan paljon RAMmia menee mihinkin ohjelmaan
htop ei välttämättä näytä yhtä tarkkoja lukuja
 

Liitteet

  • psmem.jpg
    psmem.jpg
    11,5 KB · Luettu: 47
Aina kun äänen soitto loppui, niin kuului raksahdus.

Melkoisen suurella todennäköisyydellä ongelma on äänilaitteessa joka mennessään virransäästötilaan synnyttää äänen. Korjaantunee joko estämällä laitteen powersave tai ottamalla PW:n suspend ko. sinkille pois käytöstä.
 
Mullakin oli jotain ongelmaa Pipewirellä. Aina kun äänen soitto loppui, niin kuului raksahdus. Ongelma loppui, kun heitin Pipewiren veks. Kai senkin olisi saanut jotenkin korjattua, mutta ei mitään hajua miten, ja miksi tuhlata aikaa. Mäkään en ala kokeilemaan Waylandia samasta syystä. Jos KDE nyt sitä edes tuki kunnolla vielä.
Melkoisen suurella todennäköisyydellä ongelma on äänilaitteessa joka mennessään virransäästötilaan synnyttää äänen. Korjaantunee joko estämällä laitteen powersave tai ottamalla PW:n suspend ko. sinkille pois käytöstä.

jos kyseessä on usb laite ja oli kuulokkeet tms. suoraan kiinni usb äänikortin 3.5mm plug liititmessä niin kuulokkeistahan sen raksahduksen kuulee ja pipewire jotenkin katkaisee virrat usb:hen kun se on hetken aikaa käyttämättä
jos on aktiivikajarit kytkettynä usb laitteeseen samalla tavalla, ei todennäköisesti tota edes huomaa
 
psmem ohjelma linuxille on tosi näppäri sillä sillä näkee tarkkaan paljon RAMmia menee mihinkin ohjelmaan
htop ei välttämättä näytä yhtä tarkkoja lukuja
Itse Linux / BSD puolella tykännyt myös:
Bash:
btop
ja
Bash:
bashtop
noita ennen myös
Bash:
glances
tullut vastaan.
 
Melkoisen suurella todennäköisyydellä ongelma on äänilaitteessa joka mennessään virransäästötilaan synnyttää äänen. Korjaantunee joko estämällä laitteen powersave tai ottamalla PW:n suspend ko. sinkille pois käytöstä.
Tämä on just se ongelma. En tähän hätään muista, miten ton sai korjattua, mutta löytyi kohtuu helposti googlettamalla oikea kohta asetustiedostoista. Kts. linkit lopussa.

Tällä ongelmalla ei ole mitään tekemistä Pipewiren kanssa, vaan sama ongelma tulee myös Pulseaudion kanssa, jos se on asetettu siten että se laittaa äänilaitteet virransäästötilaan (minulla nimenomaan oli tämä ongelma Pulseaudiolla). Distribuution oletusasetuksilla on hyvinkin paljon asian kanssa tekemistä, ja nyt vain on niin että aiemmalla postaajalla distribuutio (ilmeisesti) Pulseaudiolla oletuksena ei käytä em. virransäästöä, kun taas Pipewirellä käyttää.

EDIT: Asetus kannattaa ehkä jopa pitää päällä läppäreillä, vaikka aiheuttaisi poksumista, mutta ehkä säätää aikaa pidemmäksi, jos voi (ainakin PipeWirellä voi, Pulseaudiolla ei?). Pöytäkoneilla tuskin on tällä virransäästöllä mitään väliä, jatkuva poksuminen aina esim. äänimerkkiä ennen ja sen jälkeen sen sijaan on hyvin rasittavaa.

EDIT: Mahdollisesti näistä linkeistä apua - mutta kannattaa tarkistaa oma distribuution dokumentaatio, voi olla että homma toimii kuten Archissa tai sitten enemmän tai vähemmän erillä tapaa: PulseAudio/Troubleshooting - ArchWiki ja PipeWire - ArchWiki
 
Viimeksi muokattu:
jos kyseessä on usb laite ja oli kuulokkeet tms. suoraan kiinni usb äänikortin 3.5mm plug liititmessä niin kuulokkeistahan sen raksahduksen kuulee ja pipewire jotenkin katkaisee virrat usb:hen kun se on hetken aikaa käyttämättä
jos on aktiivikajarit kytkettynä usb laitteeseen samalla tavalla, ei todennäköisesti tota edes huomaa
Stereot emolle 3,5-liittimeen. Ei USB:tä.
 

Statistiikka

Viestiketjuista
258 913
Viestejä
4 495 993
Jäsenet
74 314
Uusin jäsen
bohku

Hinta.fi

Back
Ylös Bottom