Linux-kysymyksiä & yleistä keskustelua Linuxista

Eli pulseaudio ja pipewire on taso siinä välissä joka mahdollistaa useamman äänilähteen käyttävän sitä samaa audio liitäntää ja tavallaan kykenee "miksaamaan" useamman äänilähteen äänet yhteen.
JACK tarjosi vastaavanlaista ratkaisualustaa softatason miksaukselle. Mutta ei kuitenkaan ratkaissut ongelmaa jossa kun käytössä on useampi äänipalvelin. Periaatteessa jos JACKia halusi käyttää piti muut palvelimet sillata JACKin päälle joka toimi vaihtelevalla menestyksellä, lähinnä ongelmia tulee sillon jos käyttää eri mittaustaajuutta yms unohtamatta perus latency ongelmia. Periaatteessa tuon pipewirenhan voi edelleen laittaa operoimaan JACKin päälle jos haluaa jolloin JACK olla se viimeinen rajapinta joka operoi suoraan raudan kanssa.
Koodi:
Run PipeWire on top of native JACK
PipeWire can also run as a JACK client on top of the native JACK daemon if desired. See JACK and PipeWire for more information.

Toinen syy minkä takia pipewire on edelleen toivotumpi ratkaisu on että monikaan softa ei natiivisti tukenut JACKia
 
Pitkään meni itselläni siirtyessä Screenistä Tmuxiin, mutta nyt kun käyttää niin ei ole enää paluuta vanhaan. Ihan jo vaikka siitä syystä että saa jaettua ruudun kahtia, ja olla kaksi editoria auki vierekkäin. Ja irssissä saa IRC-kanavan jäsenlistan sivupalkiksi, kun käyttää Tmux plugaria :lol:
No kyllähän screenillä voi jakaa ruudun vaikka kuinka moneen osaan. Ctrl+a+S (iso S) splittaa vertikaalisesti ja Ctrl+a+| horisontaalisesti.
 
Mitä mukavampi, sen kalliimpi rahassa. Pätee jokaiseen tekniseen laitteeseen ja niiden huoltamiseen kuluvan rahan määrään. Autojen elinikä moninkertaistuisi, mikäli ihmiset huoltaisivat ne itse unohtaen kaikki mukavuustekijät. Sama pätee läppäreihin, jos useampi käyttäisi Linuxia.

Linuxissa toki esteensä valtavirtaistumiseen on, mutta audioajuri tuskin näyttelee mitään roolia siinä. Kaverini on vuodesta 2018 saakka käyttänyt samaa Ubuntun asennusta avaamatta terminalia kertaakaan. Käyttää sitä puoliammattilaisesti kuvien muokkaukseen Gimpillä. Ja ei, en itsekään uskoisi tätä väitettä ellen vierestä katsoisi.
Minusta tässä audioajuri hommassa esiintyy juuri ne avoimen softtan huonot puolet. Kasa keskeneräisiä toisistaan poikkeavia toteutuksia joita kehitentään, jos kehitetään. Ja sitten ihmitellään miksi kaupalliset yritykset suhtautuu linux tukee nuivasti. Kallista tehdä tuki 10 eri viritykselle joiden elinkelpoisuudesta ei tiedetä. Tavan käyttäjälläkään vaan ei ole mielenkiintoa käyttää useita tunteja aikaa säätämiseen niin autoissa kuin tietokoneissakaan jos erityistä kiinnostusta hommaa kohtaan ei ole.
 
Minusta tässä audioajuri hommassa esiintyy juuri ne avoimen softtan huonot puolet. Kasa keskeneräisiä toisistaan poikkeavia toteutuksia joita kehitentään, jos kehitetään. Ja sitten ihmitellään miksi kaupalliset yritykset suhtautuu linux tukee nuivasti. Kallista tehdä tuki 10 eri viritykselle joiden elinkelpoisuudesta ei tiedetä. Tavan käyttäjälläkään vaan ei ole mielenkiintoa käyttää useita tunteja aikaa säätämiseen niin autoissa kuin tietokoneissakaan jos erityistä kiinnostusta hommaa kohtaan ei ole.
Näin ehkä työpöydällä. Linux soveltuu kyllä erittäin hyvin embedded raudan kehityksen. Olen esim ollut todistamassa muutamankin kerran live keikoilla kuinka digitaalinen mikseripöytä buutannut nimenomaan linuxilla. Tämä tosin aikaa ennen kuin applesta oli tullut dominoiva tekijä markkinoilla ja pipewiresta ei oltu kuultukaan (Joskus 2010 luvun taitteessa) Eli kyllä se ammattimaiseen käyttöön skaalautuu.
 
Näin ehkä työpöydällä. Linux soveltuu kyllä erittäin hyvin embedded raudan kehityksen. Olen esim ollut todistamassa muutamankin kerran live keikoilla kuinka digitaalinen mikseripöytä buutannut nimenomaan linuxilla. Tämä tosin aikaa ennen kuin applesta oli tullut dominoiva tekijä markkinoilla ja pipewiresta ei oltu kuultukaan (Joskus 2010 luvun taitteessa) Eli kyllä se ammattimaiseen käyttöön skaalautuu.
Nuo embedded systeemi taas on monesti hyvin rajatun, muuttumattoman käyttötarkoituksen systeemejä joten kun valmistaja on ne kerran vääntänyt valmiiksi niin niitä ei monesti sen jälkeen muutella, tai päivitellä, josta päästään sitten siihen seuraavaan että on valtavasti embedded systeemejä joissa pyörii joku jeesuksen aikainen käyttisversio ilman mitään vähääkään tuoreita tietoturvapäivityksiä ja välillä taas julkaistaan tuotteita jo valmiiksi antiikkisella softalla koska se softa tekee tarvittavan. Tämähän ei sinäänsä ole ongelma, ennenkuin noilla on pääsy internettiin.
 
Nuo embedded systeemi taas on monesti hyvin rajatun, muuttumattoman käyttötarkoituksen systeemejä joten kun valmistaja on ne kerran vääntänyt valmiiksi niin niitä ei monesti sen jälkeen muutella, tai päivitellä, josta päästään sitten siihen seuraavaan että on valtavasti embedded systeemejä joissa pyörii joku jeesuksen aikainen käyttisversio ilman mitään vähääkään tuoreita tietoturvapäivityksiä ja välillä taas julkaistaan tuotteita jo valmiiksi antiikkisella softalla koska se softa tekee tarvittavan. Tämähän ei sinäänsä ole ongelma, ennenkuin noilla on pääsy internettiin.
Eikä tuo pelkästään embedded systeemeihin rajoitu. Käytännössä kaikki tuotantotason studiojärjestelmät on pääosin aika vakioituja ja softapäivitysten tarve näin ollen vähäinen.
Kyllä ne applellakin studiotyötä tekevät pyrkii minimoimaan päivitystarpeensa. Eli If it aint broken dont fixit pätee ihan yhtä lailla myös kys alustalla. rt-kerneli ja JACK kyllä soveltuu ihan perus studiokäyttikseksi DAWin kanssa joita tarjolla nykyisin ihan natiivisti linuxille. Eli edelleenkään ei se apple ainoa ole. Windowsin käytettävyydestä en jaksa edes alkaa puhumaan kaiken ASIO sekoilun kanssa vaikka "kuluttajille" softian kehitelläänkin.
 
Windowsin käytettävyydestä en jaksa edes alkaa puhumaan kaiken ASIO sekoilun kanssa vaikka "kuluttajille" softian kehitelläänkin.

Näin kuluttajan näkökulmasta tuo ASIO vaan toimii kaikessa siinä mitä itte tartten, kun taas linux puolella ei juuri mikään toimi mitä itte tartten kun ei ole tukea vielä vuosienkaan jälkeen saatu koodattua. Silloin kun linux puolelle se tuki saadaan niin se yleensä sitten toimii, mutta fyytsörit vaan tulee linuxille varsin hitaasti.
 
Näin kuluttajan näkökulmasta tuo ASIO vaan toimii kaikessa siinä mitä itte tartten, kun taas linux puolella ei juuri mikään toimi mitä itte tartten kun ei ole tukea vielä vuosienkaan jälkeen saatu koodattua. Silloin kun linux puolelle se tuki saadaan niin se yleensä sitten toimii, mutta fyytsörit vaan tulee linuxille varsin hitaasti.
Kyllä tuo pipewire tulee tarjoamaan/tarjoaa jo nyt coreaudio tasoista käytettävyyttä matalalla latencylla. Väittäisin että toiminnaltaan tulee olemaan jopa parempi vs yrität windowsissa pakottaa 32-bittistä ASIO softaa rullaamaan 64-bittisessä ASIO ympäristössä. Tai unohtamatta sitä miten eri laitteiden valmistajilla on tapana paketoida omat ajurinsa customoiduilla ASIO ajureilla ja kyseiset laitteet ei toimi juurikaan muilla ajureilla luotettavasti kuin kyseisen valmistajan omilla ja kys ajureita käytettäessä softien ristiin toimivuus onkin sitten aivan oma lukunsa.
 
Viimeksi muokattu:
Kyllä tuo pipewire tulee tarjoamaan/tarjoaa jo nyt coreaudio tasoista käytettävyyttä matalalla latencylla. Väittäisin että toiminnaltaan tulee olemaan jopa parempi vs yrität windowsissa pakottaa 32-bittistä ASIO softaa rullaamaan 64-bittisessä ASIO ympäristössä.

No itte kaipaisin sitä passtrough ominaisuutta. Ei ole näkyny eikä kuulunu. Pulseaudio sitä yritti 13.0 versiossa, mutta kusivat sen eikä kukaan ole viitsinyt korjata. Eli DD5.1 ja DTS passthrough onnistuu, mutta ei TrueHD, Atmos taikka DTS-X.
 
No itte kaipaisin sitä passtrough ominaisuutta. Ei ole näkyny eikä kuulunu. Pulseaudio sitä yritti 13.0 versiossa, mutta kusivat sen eikä kukaan ole viitsinyt korjata. Eli DD5.1 ja DTS passthrough onnistuu, mutta ei TrueHD, Atmos taikka DTS-X.
En ole ite perehtynyt tuohon passthrough käyttöön koska ei ole ollut tarvetta/monikanavaääntä kotona käytössä. Ilmeisesti kyseinen olis/on alsan kautta toteutettavissa jollain configuraatio voodoolla. Ainakin näin muistan lueksineeni. Toki jos kyseinen tulee joskus/lisättävissä pipewireen niin varmasti plussaa. Kuten sanottua tällä hetkellä käytän itse siis pulseaudiota ja satunnaisesti JACKD pohjalla kun kitaralla tulee soiteltua. Enkä oo jaksanu syventyä tuohon pipewireen vielä tarkemmin muuten kuin pintapuolisesti/demonstraatio videoiden/juttujen kautta vuosien aikana.

Mutta mitä ymmärtäsin ite niin tuota alsaa pitäis pystyä käyttämään pipewiren päällä ihan "normaalisti" eli alsan syötteet pitäis kyllä mennä pipewiren kautta ilman ongelmia :hmm:
 
En ole ite perehtynyt tuohon passthrough käyttöön koska ei ole ollut tarvetta/monikanavaääntä kotona käytössä. Ilmeisesti kyseinen olis/on alsan kautta toteutettavissa jollain configuraatio voodoolla

Joo saahan sen kun sammuttaa ensin pipen taikka pulsen ennen kodin käynnistystä ja kertoo kodille käynnistyksessä että käytä alsaa. Mutta aika huono vaihtoehto jos meinaa ajella muutakin kuin pelkkää kodia.
 
Huomasin pienen ongelman omassa "hibernate+restart" systeemissä (käynnistyy kuvakkeesta työpöydällä), jos hibernate ei toimikaan kunnolla ja joutuu laittamaan virrat poikki ja boottaamaan normaalisti takaisin, niin järjestelmään jää ohje restartata seuraavalla kerralla kun konetta taas laitetaan hibernateen (ja tässä voi olla tilanne, että ei haluta restarttia vaan virrat pois normaalisti).

Eli tiedosto /etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf luodaan tuossa omassa systeemissäni sisällöllä:
Koodi:
[Sleep]
HibernateMode=reboot

Ja tiedostolla /lib/systemd/system-sleep/disable_hibernate_reboot tuo äskeinen poistetaan kun tullaan takaisin hibernate-tilasta:
Koodi:
#!/bin/bash

if [[ -f "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf" && "$1" == "post" && "$2" == "hibernate" ]]
then
    rm "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf"
fi

Mikäs olisi paras tapa hoitaa tää? Onko jotain yhtä "/etc/systemd/" konffitiedostoa (tai pitääkö joku service tehdä?) jonka kautta saisi poistettua tuon "HibernateMode" säätötiedoston puhtaan rebootin JA hibernaten jälkeen?
 
Ja vielä tuosta audiopinosta niin jos joku ihmettelee että miksi tommosia tarttetaan niin siksi koska alsa vaikka onkin ihan mainio, on kuitenkin aika yksinkertainen. Esim. kodin saa toimimaan ihan suoraan alsan läpitte, joka taitaa tällä hetkellä olla ainut tapa jolla DD5.1 ja DTS parempia ääniä saa passthroughtina menemään vahvistimelle. Ongelma vaan on että se kodi ryövää sitten yksinoikeudella koko äänipuolen ja mistään muualta ei sitten äänet enää pihise. Tää ei tietty ole ongelma jos pyörittää vaan sitä kodia.
Eli pulseaudio ja pipewire on taso siinä välissä joka mahdollistaa useamman äänilähteen käyttävän sitä samaa audio liitäntää ja tavallaan kykenee "miksaamaan" useamman äänilähteen äänet yhteen.

ALSAn perusteet suunniteltiin silloin kun asennettujen äänikorttien enemmistö oli vielä ISA-väylässä, ja paremmissa äänikorteissa oli rautatason miksaus useamman äänilähteen yhteiskäytölle. Silloin prosessoritehot olivat niin paljon pienempiä että se kannatti, ja ALSAn kehittäjät veikkasivat että rautatason miksauksesta tulisi äänikorttien perusominaisuus. No eipä tullut, vaan tuli PCI- ja USB-väyläiset äänikortit ja useamman ääntä tuottavan ohjelman yhteenmiksaus jätettiin prosessorin vastuulle. Kehitys kääntyikin siihen suuntaan että äänikorteista karsittiin "ylimääräiset" kuten raudalla toteutetut EAX-tilaäänitoiminnot pois, koska niiden toteuttaminen ohjelmallisesti yhä nopeammilla prosessoreilla ei ollut enää mikään ongelma. Äänikorttien ominaisuudet lakkasivat kiinnostamasta valtaosaa käyttäjiä (koska perusäänipiirit olivat kaikki vähintään "tarpeeksi hyviä" peruskäyttöön), ja muotoutui standardeja rautarajapintoja: ensin AC97 ja sitten HD Audio. USB-puolella äänilaitteille saatiinkin standardimäärittely melkein alusta lähtien, joskin suht äskettäin on saatu aikaan USB Audio 2.0-laiteluokan määritys (saa nähdä mitä siitä seuraa).

Puuttuiko sitten ALSAn kehittäjiltä siviilirohkeutta lähteä ajoissa kehittämään hypoteettista ALSA 2.0:aa jossa rajapintaa olisi pistetty uusiksi siihen suuntaan että softamiksauksesta tulisi rajapinnan universaali osa, vai kävikö sitten niin että ne joille riitti äänet yhdestä ohjelmasta kerrallaan jäivät jurnuttamaan "tää on ihan hyvä, muuta ei tarvita"-moodiin, kas siinä kysymys.

Lopputulos kuitenkin oli se, että softamiksausrajapintaa piti lähteä toteuttamaan erillisenä palikkana, jonka ne jotka eivät sitä halunneet saattoivat jättää pois. Ja sitten vielä kun jotkut isot jakelut (Fedora ja Ubuntu taisivat olla ensimmäisiä) pistivät laajaan levitykseen sellaiset PulseAudion versiot jotka eivät olleet ihan täysin valmiita sellaiseen, soppa oli valmis. Asiaa ei suinkaan auttanut se että silloin PulseAudion pääkehittäjänä oli Lennart Pöttering, joka saattaa olla hyvinkin kova koodari, mutta toisten ihmisten kanssa kommunikoinnissa hänellä on ollut... hiukan haasteita.
 
vai kävikö sitten niin että ne joille riitti äänet yhdestä ohjelmasta kerrallaan jäivät jurnuttamaan "tää on ihan hyvä, muuta ei tarvita"-moodiin, kas siinä kysymys.

Veikkaan että tämä nimenomaan tapahtui.

Ja vaikka opensource homma pääsääntöisesti onkin varsin hieno homma, niin välillä hommat on vaan aivan vitun kankeita.

Tuli taas ihan hiljattain todistettua tää kun fedoran x265 (tai siis rpmfusion sitä jakelee kun ei fedoran lisenssiehtojen sisään vissiin jostain syystä oikein tuo satu) paketti on buildattu niin että 8-bit color space libraryyn lyödään hdr10plus flägi päälle (jossa mielestäni ei ole yhtään mitään järkeä koska kaikki hdr matsku vaatii vähintään 10-bit color space) mutta ei 10/12-bit color space libraryyn, joten sillä ei tehny mitään koska hdr10plus metadatan injektointi ei toiminut.

Tein bugi rapsan asiasta ja kuukauteen ei kuulunu yhtään mitään jonka jälkeen otin suoraan sähköpostilla yhteyttä henkilöön joka oli allekirjoittanu rpm .spec tiedoston muutokset viimeisimpänä. Sen jälkeen alkoi hiljalleen tapahtumaan, mutta kukaan ei tuntunu tietävän taikka käsittävän että mistä oikein on kysymys.
Lopulta kun laitoin oikein rautalanka esimerkin niin asia alettiin ymmärtää.
Alkuperäisen .spec filun tekijä ei tiennyt miksi homma oli noin tehty alkujaan, hän oli copy/pastennu sen jostain. Päätin sitten kysellä siltä sälliltä vielä asiaa joka sen oli alkujaan tehnyt ja hän taas ei enää muistanut että miksi, mutta korjasi sitten samalla omaansa tuon kanssa.
Voisin itse lonkalta veikata että x265 on tehty library puolella jossain vaiheessa isompi remontti ja ehkä jossain vaiheessa se on riittänyt että -bit libiin enabloi sen option, mutta ei riitä enää. Mutta täysin arvailua. Ei kiinnosta niin paljoa että alkaisin koodi muutoksia penkomaan kun en nyt varsinaisesti koodaamisesta ole niin kauheasti erdes perillä. Hiukan osaan päätellä jotain.

Muttä tämä saaga siis kesti kaikkiaan 2 kuukautta että saatiin lopulta yksi optio muutettua.
 
Veikkaan että tämä nimenomaan tapahtui.

Ja vaikka opensource homma pääsääntöisesti onkin varsin hieno homma, niin välillä hommat on vaan aivan vitun kankeita.

Tuli taas ihan hiljattain todistettua tää kun fedoran x265 (tai siis rpmfusion sitä jakelee kun ei fedoran lisenssiehtojen sisään vissiin jostain syystä oikein tuo satu) paketti on buildattu niin että 8-bit color space libraryyn lyödään hdr10plus flägi päälle (jossa mielestäni ei ole yhtään mitään järkeä koska kaikki hdr matsku vaatii vähintään 10-bit color space) mutta ei 10/12-bit color space libraryyn, joten sillä ei tehny mitään koska hdr10plus metadatan injektointi ei toiminut.

Tein bugi rapsan asiasta ja kuukauteen ei kuulunu yhtään mitään jonka jälkeen otin suoraan sähköpostilla yhteyttä henkilöön joka oli allekirjoittanu rpm .spec tiedoston muutokset viimeisimpänä. Sen jälkeen alkoi hiljalleen tapahtumaan, mutta kukaan ei tuntunu tietävän taikka käsittävän että mistä oikein on kysymys.
Lopulta kun laitoin oikein rautalanka esimerkin niin asia alettiin ymmärtää.
Alkuperäisen .spec filun tekijä ei tiennyt miksi homma oli noin tehty alkujaan, hän oli copy/pastennu sen jostain. Päätin sitten kysellä siltä sälliltä vielä asiaa joka sen oli alkujaan tehnyt ja hän taas ei enää muistanut että miksi, mutta korjasi sitten samalla omaansa tuon kanssa.
Voisin itse lonkalta veikata että x265 on tehty library puolella jossain vaiheessa isompi remontti ja ehkä jossain vaiheessa se on riittänyt että -bit libiin enabloi sen option, mutta ei riitä enää. Mutta täysin arvailua. Ei kiinnosta niin paljoa että alkaisin koodi muutoksia penkomaan kun en nyt varsinaisesti koodaamisesta ole niin kauheasti erdes perillä. Hiukan osaan päätellä jotain.

Muttä tämä saaga siis kesti kaikkiaan 2 kuukautta että saatiin lopulta yksi optio muutettua.
Juu, joskus on aika nihkeää saada jotain bugia korjattua tai jotain featurea aikaiseksi. Tuo 2kk on varsin lyhyt aika omien kokemuksieni mukaan.

Erääseen softaan olin lukuisten muiden kanssa pyytämässä yhtä featurea ja kuukauden päästä tuli vaan vastaus "ei toteuteta, vastaava toiminto on tulossa ihan kohta vähän eri tavalla toteutettuna". No ok, jos saman toiminnallisuuden saisi vaikka hieman eri tavalla toteutettuna niin mikäpä siinä, odotellaan... Tuo featurepyyntö oli vuonna 2017 eikä vieläkään ole tuota featurea toteutettu, eikä sen paremmin kyllä sitä "ihan kohta tulevaa" korvaavaa toiminnallisuutta ole näkynyt. Kaikkia muita, mielestäni paljon turhempia juttuja kyllä softaan lisäiltiin mutta ei tuota kyseistä. Taisi joku jonkun suunnilleen toimivan pull requestinkin laittaa mutta eipä kehittäjät sitä huolineet. Pari vuotta ihmiset jaksoivat kysellä tuon perään mutta itsekin odotellessani vaihdoin softan toiseen tuon takia.

Vastaavasti joissakin tapauksissa joidenkin softien kehittäjät ovat korjailleet ilmoittamiani bugeja tunneissa tai päivissä tai uusia featureja on tullut seuraavaan tai sitä seuraavaan releaseen joten aika vaihtelevaa meininkiä tuntuu olevan.
 
Niitä saattaa olla nihkeää saada, mutta avoin softa antaa sentään mahdollisuuden ohittaa ehkä ikuisen odottelun: opettelee koodamaan tai vaikka ottamaan sen pull requestin käyttöön itselle. Suljetun puolella ollaankin täysin kehittäjien armoilla, omien kokemusten mukaan edes niitä bugeja ei juuri jakseta korjailla jos se ei vaikuta tuottoihin, ominaisuuksia onkin jo melko turhaa toivoa..

Tämähän se. Aina on (edes teoreettinen) mahdollisuus ottaa kynä kauniiseen käteen ja tehdä itse korjaus, ja tarjota sitä PR:n tai patchin muodossa upstreamiin niin ei tarvitse kaupallisesti kehitetyn distron ilmaisversion vapaaehtoisvoimin ylläpidettyä lisärepoa odotella. Tietenkään aina niitä ei kelpuuteta, joskus vastauksena on sirkkojen sirittämistä mutta ompahan ainakin yrittänyt kantaa kortensa kekoon.


Sivumennen, Gentoon hienoimpia asioita ei ole -funroll-loops vaikka binaaridistroilijat jaksavatkin siitä viisastella. Voi itse muokata ebuildia jolla paketti kääntyy jos haluaa jotakin mihin se distron oma ei taivu. Tai voi ottaa vaikka paketin PR:n patchina matkaan lennosta paketin asennuksen yhteyteen.. tai vaikka tehdä sen korjauksen omin käsin ja tyrkyttää sitä upstreamiin.
 
Niitä saattaa olla nihkeää saada, mutta avoin softa antaa sentään mahdollisuuden ohittaa ehkä ikuisen odottelun: opettelee koodamaan tai vaikka ottamaan sen pull requestin käyttöön itselle. Suljetun puolella ollaankin täysin kehittäjien armoilla, omien kokemusten mukaan edes niitä bugeja ei juuri jakseta korjailla jos se ei vaikuta tuottoihin, ominaisuuksia onkin jo melko turhaa toivoa.. Millaista ominaisuutta pyysit?
Tuo feature olisi ollut ihan konfiguraatiofileen parsintaan tuki rangelle, ettei olisi joutunut kirjoittamaan 100 ja 1 kertaa samaa asiaa konfiguraatioon, tyyliin:
Koodi:
[entry]
id=1
param=true
[entry]
id=2
param=true
[entry]
id=3
param=true

eli että tuon olisi saanut vaikka muotoon

[entry]
id=[1-3]
param=true
Noita entry-blokkeja olisi omassa käytössä ollut kymmeniä joten jonkinlainen range-määritys olisi ollut varsin kätevä. Jos käytetty kieli olisi ollut joku mitä olisin osannut, olisin varmaan harkinnut oman forkin tekoa. Tosin, sitten tulevaisuuden tietoturvapäivitysten kanssa olisi kyllä tullut oma hommansa kun olisi itse pitänyt hoidella päivitykset.

Jonkin verran olenkin C/C++/Python -softista tehnyt omia privaattiversioita jos ovat olleet sellaisia joissa en ole nähnyt kovin suurta riskiä että päivityksiä ei omien muutosten jälkeen saisikaan helposti mukaan ympättyä. Ihan mielellään en noita kuitenkaan rupea tekemään kun en mikään oikea koodari ole eikä oikein aika riitä kaiken mahdollisen ylläpitämiseen.
 
Tämähän on varmaan täysin linuxin periaatteiden vastainen jo ajatuksena, mutta onkohan olemassa jotain ubuntulla toimivaa yksinkertaista, helppokäyttöistä FTP serveriä joka olisi näppärä väliaikaiseen käyttöön. Eli siis, käyttö tulisi olemaan sitä kun erilaisiin laitteisiin tarvitsisi FTP:llä ladata softaa tai konffista tai päinvastoin eli laitteessa on siis client joka ottaa yhteyttä läppärillä olevaan serveriin tiedostojen siirtämiseksi. Tarve on ajoittaista joten pitäisi olla sellainen mikä on vaivaton laittaa päälle ja pois.
 
Onko pakko olla ftp? Esim pythonilla voi ajaa python -m http.server niin se jakelee nykyistä hakemistoa portissa 8080 (muistaakseni).
 
Onko pakko olla ftp? Esim pythonilla voi ajaa python -m http.server niin se jakelee nykyistä hakemistoa portissa 8080 (muistaakseni).
On pakko olla FTP, sillä nuo siis on erilaisia verkkolaitteita yms ja toiminta logiikka on että niitä laitteen hallinnasta komennetaan muodostamaan ftp yhteys johonkin osoitteeseen ja sitten lataamaan suuntaan tai toiseen tiedostoja.
 
Tämähän on varmaan täysin linuxin periaatteiden vastainen jo ajatuksena, mutta onkohan olemassa jotain ubuntulla toimivaa yksinkertaista, helppokäyttöistä FTP serveriä joka olisi näppärä väliaikaiseen käyttöön. Eli siis, käyttö tulisi olemaan sitä kun erilaisiin laitteisiin tarvitsisi FTP:llä ladata softaa tai konffista tai päinvastoin eli laitteessa on siis client joka ottaa yhteyttä läppärillä olevaan serveriin tiedostojen siirtämiseksi. Tarve on ajoittaista joten pitäisi olla sellainen mikä on vaivaton laittaa päälle ja pois.
modeemireitittimissä on yleensä ftp-palvelinkin, jos sellainen riittää?
 
modeemireitittimissä on yleensä ftp-palvelinkin, jos sellainen riittää?
Tämä tulee käytettäväksi muualla kuin kotiverkossa ja tarkoitus olisi saada konffi läppärille sellainen toteutus että sen käyttö olisi vaivatonta muissakin FTP:tä vaativissa tilanteissa.

Mitä noita googletteli, niin FTP servereitä linuxille on pilvin pimein, mutta monet noista on tarkoitettu jatkuvaan "oikeaan" FTP käyttöön ja täten kovin kankeita. Esim koneen IP osoitteen vaihto ei saisi aiheuttaa ongelmaa.
 
Tämä tulee käytettäväksi muualla kuin kotiverkossa ja tarkoitus olisi saada konffi läppärille sellainen toteutus että sen käyttö olisi vaivatonta muissakin FTP:tä vaativissa tilanteissa.
pip3 install pyftpdlib
python3 -m pyftpdlib - jakelee nykyisen hakemiston ilman kirjoitusoikeuksia (anonymous login) portissa 2121
python3 -m pyftpdlib --write --port 21 - jakelee nykyisen hakemiston kirjoitusoikeuksilla(anonymous login) portissa 21

Testailin tätä nopeasti ja vaikuttaisi ihan näppärältä väliaikaistarkoituksiin.
 
pip3 install pyftpdlib
python3 -m pyftpdlib - jakelee nykyisen hakemiston ilman kirjoitusoikeuksia (anonymous login) portissa 2121
python3 -m pyftpdlib --write --port 21 - jakelee nykyisen hakemiston kirjoitusoikeuksilla(anonymous login) portissa 21

Testailin tätä nopeasti ja vaikuttaisi ihan näppärältä väliaikaistarkoituksiin.
Tämä.... oli parempi kuin 100 jänistä. Todella helppo ja vaivaton. Kiitos vain paljon!
 
Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?
 
Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?
Oisko kameralla mahis lähettää kuvia muutenkuin sähköpostina? Kuvat suoraan sinne minne halutaan ilman liitetiedostojen kans säätämistä.
 
Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?
Sama tunne itsellä, pitää hieman osata koodata, jos haluaa käyttää Linuxia tuohon. On Linuxiinkin maksullisia softia, mutta yleensä halutaan helposti ja ilmaisena. Windowsissa Power Bi on ilmainen ja tekee tuon tosi helposti.
 
Tämähän on varmaan täysin linuxin periaatteiden vastainen jo ajatuksena, mutta onkohan olemassa jotain ubuntulla toimivaa yksinkertaista, helppokäyttöistä FTP serveriä joka olisi näppärä väliaikaiseen käyttöön. Eli siis, käyttö tulisi olemaan sitä kun erilaisiin laitteisiin tarvitsisi FTP:llä ladata softaa tai konffista tai päinvastoin eli laitteessa on siis client joka ottaa yhteyttä läppärillä olevaan serveriin tiedostojen siirtämiseksi. Tarve on ajoittaista joten pitäisi olla sellainen mikä on vaivaton laittaa päälle ja pois.
vsftpd on ainakin ollut Ubuntulle: Service - FTP | Ubuntu
Tosin nuo aiemmin mainitut python-palikat lienevät hetkittäiseen käyttöön vielä selvempiä.
 
Oisko kameralla mahis lähettää kuvia muutenkuin sähköpostina? Kuvat suoraan sinne minne halutaan ilman liitetiedostojen kans säätämistä.
Tuo ei ole mahdollista.
Sama tunne itsellä, pitää hieman osata koodata, jos haluaa käyttää Linuxia tuohon. On Linuxiinkin maksullisia softia, mutta yleensä halutaan helposti ja ilmaisena. Windowsissa Power Bi on ilmainen ja tekee tuon tosi helposti.
Koodaaminen itsessään ei ole ongelma, mutta tuli epäusko että onko tuo tosiaan noin monimutkainen toteuttaa.
 
Koodaaminen itsessään ei ole ongelma, mutta tuli epäusko että onko tuo tosiaan noin monimutkainen toteuttaa.
No onhan se koko ajatuskin tuosta pöljä. Sinun syyhän se ei ole vaan valmistajan, joka sallii vain sähköpostien lähettämisen pelkän datan sijaan. Tuossa sit pitää lukea sähköpostiviestejä ja hakea sieltä liitetiedostoja. Asiaa helpottaa, jos kameralle on oma sähköposti-tili, nii säästyy sentäs filtteröinniltä. Joka tapauksessa ihan turhaa purkkaa, mut ei kyl auta sun ongelmassa yhtää tämä vuodatus :D
 
Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?
Vähän googlettelin ja tällainen projekti voisi toimia GitHub - auino/mail-attachments-archiver: Store mail attachments to file-system.
 
Siinähän tosiaan näyttäisi olevan valmis ratkaisu.
Heh, tuohan näyttäisi olevan melkein samanlainen tekele mitä itse puolisen vuotta sitten tein itselleni väliaikaiseksi työkaluksi vastaavaan ongelmaan. Eli simppeli mailiserveri joka huoli vain tietyiltä lähettäjiltä sähköpostia tietyillä otsikkotiedoilla ja tallensi liitetiedostot viestin sisällön mukaan tietyllä logiikalla eri kansioihin. Olisi siis kannattanut googlettaa ensin niin ei olisi tarvinnut itse yhtä iltaa käyttää koodaamiseen :D
 
Heh, tuohan näyttäisi olevan melkein samanlainen tekele mitä itse puolisen vuotta sitten tein itselleni väliaikaiseksi työkaluksi vastaavaan ongelmaan. Eli simppeli mailiserveri joka huoli vain tietyiltä lähettäjiltä sähköpostia tietyillä otsikkotiedoilla ja tallensi liitetiedostot viestin sisällön mukaan tietyllä logiikalla eri kansioihin. Olisi siis kannattanut googlettaa ensin niin ei olisi tarvinnut itse yhtä iltaa käyttää koodaamiseen :D
Olisit jääny paitsi "koodaamisen" ilosta.
 
Koodaaminen itsessään ei ole ongelma, mutta tuli epäusko että onko tuo tosiaan noin monimutkainen toteuttaa.

Monimutkainen on varmaan maku asia. Linux maailmassa kannattaa ajatusmallina pitää se että löytyy työkaluja vaikka mihin jotka tekee jonkun yhden asian ja yleensä sen ne tekee sitten hyvin.
Monesti kun jotain tarttee niin näitä työkaluja yhdistelemällä ja scriptaamalla saa asiat hoidettua melko vaivattomasti. Itse kun en sinäänsä koodata osaa niin tuota asiaa olisin varmaan lähtenyt ratkomaan ensin fetchmailin kanssa jonka siis saa hakemaan mailit serveriltä ja sitten ettiny seuraavan kikkareen jolla ne mailit voi komuta läpi talletella liitteet.
 
Joo, munpackilla tai ripmimella, jos jotain kiinnostaa, olisi saanut mailista liitteet eroteltua, sen olisi saanut vaikka ihan tavan mailiclientin johonkin hookkiin lisättyä ja sitten vain siirto levylle. Nämä varmaan tuli JKAVS:lla etsiessä vastaankin.
 
Yleensä kai asennusjärjestys ensin winukka, sitten Linux, mutta nyt kun vanhalla työläppärillä on jo Linux mietin millainen operaatio olis asentaa Windows samalle läppärille?

Windows olis parin softaseikan taki tuleva sivutuloyrittäjän puoli ja Linuxilla kaikki muu käyttö.
 
Yleensä kai asennusjärjestys ensin winukka, sitten Linux, mutta nyt kun vanhalla työläppärillä on jo Linux mietin millainen operaatio olis asentaa Windows samalle läppärille?

Windows olis parin softaseikan taki tuleva sivutuloyrittäjän puoli ja Linuxilla kaikki muu käyttö.
Tässä on ohjeet:

En anna takuuta, koska joka kerta kun olen moista kokeillut, on Windows ylikirjoittanut Linuxin EFI-partition, vaikka se (Linuxin EFI-partitio) olisi sijainnut levyn lopussa ja manuaalisesti tehnyt EFI-partition Windowsille erikseen tai olisin juuri poistanut Windowsin omat osiot eli asentanut Windowsia uudestaan.

Kloonaa levy tai tee muunlaiset backupit, jos edes kokeilet.
 
Tässä on ohjeet:

En anna takuuta, koska joka kerta kun olen moista kokeillut, on Windows ylikirjoittanut Linuxin EFI-partition, vaikka se (Linuxin EFI-partitio) olisi sijainnut levyn lopussa ja manuaalisesti tehnyt EFI-partition Windowsille erikseen tai olisin juuri poistanut Windowsin omat osiot eli asentanut Windowsia uudestaan.

Kloonaa levy tai tee muunlaiset backupit, jos edes kokeilet.
Aikalailla vastaavasti olen itse tehnyt pari kertaa ja tosiaan pientä säätöä saattaa olla grubin ja EFI:n kanssa mutta teoriassa pitäisi mennä liki heittämällä noiden ohjeiden mukaan.

Tietty jos windows-tarve on vain satunnaista niin riittäisiköhän ihan vaan virtuaalikoneeseen asennettu windows? Itse olen vmware playerilla pyöritellyt parissa koneessa windowsia tarpeen mukaan kun tiettyjen softien takia hyvin satunnaisesti windowsia tarvitsen.
 
Osaiskohan joku auttaa seuraavassa:
- Tietokoneena on Lenovo T14, Ubuntu 22.04 LTS
- Työpaikan VPN-yhteys on Cisco Anyconnect-pohjainen
- Minulla on asennettuna openconnect sekä network-manager-openconnect-gnome paketit
- Kirjautuminen käyttää CA-certifikaattia, AD-tunnusta ja MFA-koodia

Aloitan VPN-yhteyden graafisessa käyttöliittymässä. Kun klikkaan VPN-ikonia, avautuu NetworkManagerin ikkunaan AD-kirjautumisikkuna, johon kirjoitan käyttäjätunnuksen/salasanan ja sen jälkeen pyydettäessä MFA-koodin. Yleensä ensimmäisellä kerralla VPN-yhteydenotto sujuu hyvin. Jos kuitenkin kytken VPNn pois ja yritän ottaa yhteyden uudestaan, NetworkManager kaatuu. Se kaatuu jokaisella uudelleenyrityksellä, kunnes käynnistän koneen uudestaan.

Välillä käy kuitenkin myös näin, heti ensimmäisestä yrityksestä alkaen:
- Kun valitsen VPNn, koko Network-Managerin ikkuna avautuu, ja pian kaatuu
TAI
- Kun olen kirjoittanut salasanan, Network-Managerin ikkuna kaatuu hiljaisuudessaan
TAI YLEISIN
- Kun olen kirjoittanut MFA-salasanan, Network-Managerin ikkuna kaatuu (tämä on se sama tilanne, joka tapahtuu jos VPN-yhteys tippuu ja pitäisi ottaa se uudelleen)

Mitään kaatumisilmoituksia tai virheestäilmoitus dialogeja ei tule, tuo graafinen ikkuna vaan häviää ruudulta. Jos VPN-yhteydenotto toimii, ei silloinkaan tapahdu kirjautumisen jälkeen muuta kuin ikkunassa ehtii näkymään vaaleansininen "Cisco Anyconnect" banneri, jonka jälkeen ikkuna sulkeutuu automaattisesti, mutta yläkulmaan ilmestyy VPN-ikoni eli yhteys on selvästi päällä.

Jos tuo NetworkManager häviää alta kesken kaiken ja katson logeista journalctl -u NetworkManager.service , virhe on käytännössä aina:
Koodi:
NetworkManager[1268]: <info>  [1673939037.3866] agent-manager: agent[05edb809d5a47885,:1.110/org.gnome.Shell.NetworkAgent/1000]: agent registered
NetworkManager[1268]: <info>  [1673939052.4984] vpn[0x562ae10f41e0,UUID,"VPN NAME"]: starting openconnect
NetworkManager[1268]: <info>  [1673939052.4990] audit: op="connection-activate" uuid="UUID" name="VPN NAME" pid=3615 uid=1000 result="success"
NetworkManager[1268]: <warn>  [1673939075.6011] vpn[0x562ae10f41e0,UUID,"VPN NAME"]: secrets: failed to request VPN secrets #3: No agents were available for this request.

ArchLinuxin ohjeissa ollut vinkki yritetty symbolisen linkin luomiseen ( NetworkManager - ArchWiki ) , mutta se ei ole mielestäni erityisesti parantanut tai huonontanut tilannetta.

Yleensä selviän ongelmasta yhdellä koneen restartilla, mutta tänään sain käynnistää koneen kolme kertaa ennen kuin homma alkoi pelittämään. Välissä ehdin jo hetkeksi siirtyä openfortivpn -varaVPN-yhteyteen, mutta tämä OpenConnect on noin muuten ollut varsinaisen yhteyden suhteen niin paljon varmempi että sitä mieluummin käytän.
 
Osaiskohan joku auttaa seuraavassa:
- Tietokoneena on Lenovo T14, Ubuntu 22.04 LTS
- Työpaikan VPN-yhteys on Cisco Anyconnect-pohjainen
- Minulla on asennettuna openconnect sekä network-manager-openconnect-gnome paketit
- Kirjautuminen käyttää CA-certifikaattia, AD-tunnusta ja MFA-koodia

Aloitan VPN-yhteyden graafisessa käyttöliittymässä. Kun klikkaan VPN-ikonia, avautuu NetworkManagerin ikkunaan AD-kirjautumisikkuna, johon kirjoitan käyttäjätunnuksen/salasanan ja sen jälkeen pyydettäessä MFA-koodin. Yleensä ensimmäisellä kerralla VPN-yhteydenotto sujuu hyvin. Jos kuitenkin kytken VPNn pois ja yritän ottaa yhteyden uudestaan, NetworkManager kaatuu. Se kaatuu jokaisella uudelleenyrityksellä, kunnes käynnistän koneen uudestaan.

Välillä käy kuitenkin myös näin, heti ensimmäisestä yrityksestä alkaen:
- Kun valitsen VPNn, koko Network-Managerin ikkuna avautuu, ja pian kaatuu
TAI
- Kun olen kirjoittanut salasanan, Network-Managerin ikkuna kaatuu hiljaisuudessaan
TAI YLEISIN
- Kun olen kirjoittanut MFA-salasanan, Network-Managerin ikkuna kaatuu (tämä on se sama tilanne, joka tapahtuu jos VPN-yhteys tippuu ja pitäisi ottaa se uudelleen)

Mitään kaatumisilmoituksia tai virheestäilmoitus dialogeja ei tule, tuo graafinen ikkuna vaan häviää ruudulta. Jos VPN-yhteydenotto toimii, ei silloinkaan tapahdu kirjautumisen jälkeen muuta kuin ikkunassa ehtii näkymään vaaleansininen "Cisco Anyconnect" banneri, jonka jälkeen ikkuna sulkeutuu automaattisesti, mutta yläkulmaan ilmestyy VPN-ikoni eli yhteys on selvästi päällä.

Jos tuo NetworkManager häviää alta kesken kaiken ja katson logeista journalctl -u NetworkManager.service , virhe on käytännössä aina:
Koodi:
NetworkManager[1268]: <info>  [1673939037.3866] agent-manager: agent[05edb809d5a47885,:1.110/org.gnome.Shell.NetworkAgent/1000]: agent registered
NetworkManager[1268]: <info>  [1673939052.4984] vpn[0x562ae10f41e0,UUID,"VPN NAME"]: starting openconnect
NetworkManager[1268]: <info>  [1673939052.4990] audit: op="connection-activate" uuid="UUID" name="VPN NAME" pid=3615 uid=1000 result="success"
NetworkManager[1268]: <warn>  [1673939075.6011] vpn[0x562ae10f41e0,UUID,"VPN NAME"]: secrets: failed to request VPN secrets #3: No agents were available for this request.

ArchLinuxin ohjeissa ollut vinkki yritetty symbolisen linkin luomiseen ( NetworkManager - ArchWiki ) , mutta se ei ole mielestäni erityisesti parantanut tai huonontanut tilannetta.

Yleensä selviän ongelmasta yhdellä koneen restartilla, mutta tänään sain käynnistää koneen kolme kertaa ennen kuin homma alkoi pelittämään. Välissä ehdin jo hetkeksi siirtyä openfortivpn -varaVPN-yhteyteen, mutta tämä OpenConnect on noin muuten ollut varsinaisen yhteyden suhteen niin paljon varmempi että sitä mieluummin käytän.
Itse olen törmännyt tuohon samaan, eli NetworkDamagerin kanssa tuo AnyConnect on melkoisen epävakaa. Nykyään minun ei onneksi sitä tarvitse käyttää kun pystyn käyttämään OpenVPN:ää. Minulla oli joku komentoriviloitsu joka loi tuon Ciscon VPN-tunnelin ilman NetworkDamageria ja se toimi jonkun verran luotettavammin mutta ei sekään täydellinen ollut. Googlella varmaan löytyy jotain tietoja miten tuo rakennettiin. Muistaakseni piti asentaa joku Ciscon oma AnyConnect-softa ja jollakin skriptillä käskyttää sitä.
 
Mikäs voisi aiheuttaa tämmöistä: Eli proxmox missä ubuntu serveri jossa valheim peli serveri dockerillä. Olen laittanut cronilla menemään kerran päivässä pelin world kansiosta backupin verkkokiintolevylle " * 21 * * * rsync -av /home/valheim-server/config/worlds_local/ /media/backup/ " Mutta tämä alkaa tekemään root hakemistoon /cron./cron./cron. kansioita jotka on kaikki täynnä noita backupattavia tiedostoja ja nämä täyttää serverin kiintolevyn muutamassa päivässä.
crontab on normaali käyttäjällä ei rootilla. ja itse backup menee ihan normaalisti ja oikein tuonne verkkolevylle. Mitä en nyt huomaa tässä? Kauhean paljon kokemusta ei ole tämän serverin kanssa säätämisestä
 
Olen laittanut cronilla menemään kerran päivässä pelin world kansiosta backupin verkkokiintolevylle " * 21 * * * rsync -av /home/valheim-server/config/worlds_local/ /media/backup/ " Mutta tämä alkaa tekemään root hakemistoon /cron./cron./cron. kansioita jotka on kaikki täynnä noita backupattavia tiedostoja ja nämä täyttää serverin kiintolevyn muutamassa päivässä.

Ensinnäkin, tuo tekemäsi määritys ajetaan joka päivä 60 kertaa (= kerran minuutissa) aikavälillä 21:00 .. 21:59.
Jos haluat että tuo komento ajetaan vain kerran päivässä, myös minuuttilukema pitää lyödä kiinni eikä laittaa sen paikalle tähteä.
(Et ole yksin tuon virheen kanssa: hyvin moni cronin käyttöä aloitteleva tekee ensin noin. Ai mistäkö tiedän?? ;))

Toiseksi, optio -v laittaa rsyncin kertomaan tekemisistään mahdollisimman paljon. Jos et kerro mihin tämä tuloste laitetaan, sitä yritetään lähettää sähköpostina työn omistajalle, ja jos sähköpostiasetukset eivät ole kunnossa tai koneessa/kontissa ei edes ole paikallista sähköpostipalvelua asennettuna, sitten tuloste voi päätyä tiedostona rootille. Nuo /cron. jotain tiedostot/kansiot saattaisivat olla seurausta tästä ja/tai siitä että uusi cron-työ yrittää käynnistyä ennen kuin entinen on ehtinyt päättyä.

Eli jos esimerkiksi haluat varmuuskopion kerran päivässä kello 21:30:
Koodi:
30 21 * * * rsync -av /home/valheim-server/config/worlds_local /media/backup/ >/media/backup/viimeisin-valheimbackup.log 2>&1

Tuossa ">/media/backup/viimeisin-valheimbackup.log 2>&1" sanoo että rsyncin sekä rutiinitulosteet että virheilmoitukset ohjataan viimeisin-valheimbackup.log-nimiseen tiedostoon, siten että uudempi ajo aina ylikirjoittaa edellisen login.

Lisäksi sillä laittaako rsyncillä lähdehakemiston perään kauttaviivan vai ei on väliä:
- kauttaviivan kanssa: kopioidaan kaikki tiedostot annetusta hakemistosta (eli tässä tapauksessa syntyy /media/backup/<kasa valheim-maailman tiedostoja>)
- ilman kauttaviivaa: kopioidaan lähdehakemisto sisältöineen kohteeseen (syntyy /media/backup/worlds_local/ ja sen alle valheim-maailman tiedostot, minusta selkeämpää näin.)
 
Ensinnäkin, tuo tekemäsi määritys ajetaan joka päivä 60 kertaa (= kerran minuutissa) aikavälillä 21:00 .. 21:59.
Jos haluat että tuo komento ajetaan vain kerran päivässä, myös minuuttilukema pitää lyödä kiinni eikä laittaa sen paikalle tähteä.
(Et ole yksin tuon virheen kanssa: hyvin moni cronin käyttöä aloitteleva tekee ensin noin. Ai mistäkö tiedän?? ;))

Toiseksi, optio -v laittaa rsyncin kertomaan tekemisistään mahdollisimman paljon. Jos et kerro mihin tämä tuloste laitetaan, sitä yritetään lähettää sähköpostina työn omistajalle, ja jos sähköpostiasetukset eivät ole kunnossa tai koneessa/kontissa ei edes ole paikallista sähköpostipalvelua asennettuna, sitten tuloste voi päätyä tiedostona rootille. Nuo /cron. jotain tiedostot/kansiot saattaisivat olla seurausta tästä ja/tai siitä että uusi cron-työ yrittää käynnistyä ennen kuin entinen on ehtinyt päättyä.

Eli jos esimerkiksi haluat varmuuskopion kerran päivässä kello 21:30:
Koodi:
30 21 * * * rsync -av /home/valheim-server/config/worlds_local /media/backup/ >/media/backup/viimeisin-valheimbackup.log 2>&1

Tuossa ">/media/backup/viimeisin-valheimbackup.log 2>&1" sanoo että rsyncin sekä rutiinitulosteet että virheilmoitukset ohjataan viimeisin-valheimbackup.log-nimiseen tiedostoon, siten että uudempi ajo aina ylikirjoittaa edellisen login.

Lisäksi sillä laittaako rsyncillä lähdehakemiston perään kauttaviivan vai ei on väliä:
- kauttaviivan kanssa: kopioidaan kaikki tiedostot annetusta hakemistosta (eli tässä tapauksessa syntyy /media/backup/<kasa valheim-maailman tiedostoja>)
- ilman kauttaviivaa: kopioidaan lähdehakemisto sisältöineen kohteeseen (syntyy /media/backup/worlds_local/ ja sen alle valheim-maailman tiedostot, minusta selkeämpää näin.)
Okei tuo selittää jo hieman, "luulin" tajunneeni tuon cronin ajastuksen aikani googleteltua, mutta en ihan selvästikään :D Pitääpä kokeilla tuolla jos toimisi, eniten hämmennystä herätti nimenomaan se, että meni root kansion juureen nuo /cron./cron. kansiot ja backupattavat tiedostot vaikka croni ajettiin normaalikäyttäjällä. Ja siis ne tiedostot meni tuonne cron. kansioihin sekä verkkolevylle molempiin.
Harrastus mielessä hommasin vanhan hp elitedeskin ja ajattelin proxmoxilla alkaa harjotteleen, tuo valheim serveri nyt oli toistaiseksi ainoa mitä "oikeasti" tarvi tässä.
 
Ja jos ei kiinnosta noi rsyncin tulosteet/virheet, eli kun on testannut että homma toimii, niin voi korvata tuon >/media/backup/viimeisin-valheimbackup.log tällä >/dev/null jolloin ne rsyncin ulosteet ja virheet haihtuu bittiavaruuteen kuin pieru saharaan.
 
Okei tuo selittää jo hieman, "luulin" tajunneeni tuon cronin ajastuksen aikani googleteltua, mutta en ihan selvästikään :D Pitääpä kokeilla tuolla jos toimisi, eniten hämmennystä herätti nimenomaan se, että meni root kansion juureen nuo /cron./cron. kansiot ja backupattavat tiedostot vaikka croni ajettiin normaalikäyttäjällä. Ja siis ne tiedostot meni tuonne cron. kansioihin sekä verkkolevylle molempiin.
Harrastus mielessä hommasin vanhan hp elitedeskin ja ajattelin proxmoxilla alkaa harjotteleen, tuo valheim serveri nyt oli toistaiseksi ainoa mitä "oikeasti" tarvi tässä.
Itsekin olen aikanaan sekoillut noiden cronin ajastusten kanssa. Tosiaan niiden kanssa saa olla tarkkana ettei vahingossa tee sellaisia ajastuksia jotka liipovat joka minuutti tai totaalisen väärään aikaan. Itse olen käyttänyt noiden kanssa kikkailuun Crontab Gurua ( Crontab.guru - The cron schedule expression editor ) jolla on helppo katsoa oliko oma ajastus-avopieru sinnepäinkään mitä ajatteli.
 
Ja jos ei kiinnosta noi rsyncin tulosteet/virheet, eli kun on testannut että homma toimii, niin voi korvata tuon >/media/backup/viimeisin-valheimbackup.log tällä >/dev/null jolloin ne rsyncin ulosteet ja virheet haihtuu bittiavaruuteen kuin pieru saharaan.

Toisaalta verkkolevyjen kanssa turatessa joskus sattuu ja tapahtuu, tällöin voi olla ikävä niitä virheilmoituksia. Itse ennemmin vaihtaisin aiemmin mainitun -v option -q optioon niin ei tule hyödytöntä törkyä.
 
Tässä on ohjeet:

En anna takuuta, koska joka kerta kun olen moista kokeillut, on Windows ylikirjoittanut Linuxin EFI-partition, vaikka se (Linuxin EFI-partitio) olisi sijainnut levyn lopussa ja manuaalisesti tehnyt EFI-partition Windowsille erikseen tai olisin juuri poistanut Windowsin omat osiot eli asentanut Windowsia uudestaan.

Kloonaa levy tai tee muunlaiset backupit, jos edes kokeilet.
Aikalailla vastaavasti olen itse tehnyt pari kertaa ja tosiaan pientä säätöä saattaa olla grubin ja EFI:n kanssa mutta teoriassa pitäisi mennä liki heittämällä noiden ohjeiden mukaan.

Tietty jos windows-tarve on vain satunnaista niin riittäisiköhän ihan vaan virtuaalikoneeseen asennettu windows? Itse olen vmware playerilla pyöritellyt parissa koneessa windowsia tarpeen mukaan kun tiettyjen softien takia hyvin satunnaisesti windowsia tarvitsen.
Kiitos ohjeista, täytyy kokeilla. Nyt ei ole paljoa backupattavaa koska ollut vaan surffailukäytössä. Tuo virtuaalikone vois tulla kuuloon myös, mutta en tunne kovin hyvin hommaa. Vaikuttaakohan kuinka paljon suorituskykyyn?
 

Statistiikka

Viestiketjuista
301 411
Viestejä
5 130 455
Jäsenet
81 984
Uusin jäsen
Sokka

Hinta.fi

Back
Ylös Bottom