Näytä kirjoitukset

Tässä osiossa voit tarkastella kaikkia tämän jäsenen viestejä. Huomaa, että näet viestit vain niiltä alueilta, joihin sinulla on pääsy.


Viestit - ajaaskel

Sivuja: 1 [2] 3 4 ... 169
21
Jos ei halua olla itse html-koodin kanssa paljon tekemisissä niin Seamonkey webbiselaimessa on myös Edit-tila (Ctrl-E) , pystyy graafisesti editoimaan html-sivuja.
Sen "Composer" osan voi virittää suoraan käynnistymään omasta kuvakkeesta.
Yksinkertaisia stattisia html-sivuja tuolla muokkaa helposti ja nopeasti.
Tekee hieman ruman näköistä html koodia -- joka silti näyttäisi toimivan odotetulla tavalla selaimissa eli käy yksinkertaisiin juttuihin hyvin.
Muita yksinkertaisia "rumia" keinoja on tallettaa LibreOfficen tai OpenOfficen Writestä html-muodossa.
Tuosta Writestä voisi saada aika kätevän Wysiwyg-editorin jos olisi aikaa viritellä/sovitella se siihen tarkoitukseen.
Inkscape: llakin pystyy tekemään webbisivuja (!) ja layout on helppo mättää graafisesti miten päin haluaa...  keinot on monet  :)

html-editointi onnistuu millä tahansa editorilla. Itse olen käyttänyt usein Geany -editoria (asennettava erikseen). 

Ns. "hienompien" sivujen tekoon on WordPress omalla tavallaan kätevä mutta ylläpito ja sen logiikan ymmärtäminen myös monimutkaisempaa. 

22
Elkohan sen jännitteen tasoittaa ja tantaalimalli lienee suositeltava.
En pysty arvaamaan olisiko tasajännitteen päällä ratsastava häiriö tuhonnut jotain. Sekottamaan toiminnan se varmasti pystyy.

Itse asennus, taitaisi olla helpompi kiertää ongelma ja asentaa CD: ltä noihin vanhimman polven koneisiin. 

Itse USB-käynnistys tikulta (koneen BIOS: in ominaisuus) voi olla sangen ronkkeli ja vanhimmat koneet eivät osaa USB-käynnistystä ollenkaan.
Etu- ja takaseinän porteissa voi olla eroa, kannattaa yleensä ensisijaisesti yrittää takaseinän porttia/portteja. 
Jos haluaa testailla edelleen tikkukäynnistystä niin voisi kokeilla tehdä sen tikun "Unetbootin"  -ohjelmalla.
Jos se oli jo tehty sen avulla niin nostan käteni pystyyn.

23
Ehdottaisin, että asennat x11vnc -ohjelman (eikä vnc) sinne etäpäähän jota haluat katsella ja omalle koneellesi ssvnc -ohjelman.

Tuo tekee mitä haluat ainakin PC: llä, näkyy desktop kaikkineen ok,  Raspiin en ole sitä koskaan virittänyt.

24
Kun levy näyttä tältä:

http://www.homelinuxpc.com/download/broken_disk_toshiba_2TB_2018-06-08%2023:26:43.png

voi olla pientä puuhaa tiedossa. 

Kaikki ei mennyt vaihdossa ensin ihan suoraviivaisesti.  Kirjoittelin lisäosan tuon muistiinpanoni loppuun RAID5-pakassa olevan levyn uusimisesta:

http://www.homelinuxpc.com/download/software_raid.html

Lyhyesti, tärkeintä on kertoa Raidille, että levy otetaan irti pakasta ennen kuin sammuttaa koneen ja vaihtaa uuden levyn viallisen tilalle.
Tuolloin jäljellä olevat ehjät levyt jatkavat heti toimintaansa ilman hankaluuksia.
   

25
Laitoin tuon vaihtoehdon "B" valmiina .reg tiedostona esille, helpottaa etenkin jos pitää tehdä tuo muutos useampaankin koneeseen:

http://www.homelinuxpc.com/download/Fix_Win_Time_to_UTC.reg

Käyttö:  Lataus, tuplaklikka Windowsissa kyseistä .reg-tiedostoa ja Windows asentaa tuon asetuksen.

26
Kysyitkö googlelta?

Laitoin palautekanavan kautta kysymyksen.
Meni hetki kyllä löytää se ensin.

27
Miten olisi akku pois koneesta hetkeksi että käynnistyy varmasti alusta asti eikä ole mikään Windowsin palikka muistissa myös koneen ollessa "sammuksissa".
Heti sen jälkeen käynnistettäessä luultavasti nuo Dellin F-näppäimet saavat odotettua toimintaa aikaan. Jos tuo ei auta niin levy pois, kerran käyntiin ilman levyä ja levy takaisin.  Voi kuulostaa erikoiselta   :)
Ihmettelin kerran aiemmin tuota samaa ilmiötä ja Dell oli läppäsi silloinkin (i5).  Halusi aina käynnistää Windowsin teki mitä hyvänsä näppäimistöllä, ikään kuin Windows ei olisi sammunut kokonaan.

28
Yleistä keskustelua / Gmail blokkasi asennusohjeen
« : 19.05.18 - klo:18.40 »
Kirjoittelin itselleni ylös muistiinpanoja Let's Encrypt: in asennukseen liittyvistä jutuista ja lähetin sen sähköpostilla Gmail boxiini.   

Yllätys:  Gmail käännytti sen takaisin "vaarallisena".:

Lainaus
host gmail-smtp-in.l.google.com[2a00:1450:400c:c00::1b]
    said: 552-5.7.0 This message was blocked because its content presents a
    potential 552-5.7.0 security issue. Please visit 552-5.7.0
    https://support.google.com/mail/?p=BlockedMessage to review our 552 5.7.0
    message content and attachment content guidelines. j5-v6si7834037wrm.199 -
    gsmtp (in reply to end of DATA command)
   

Testi oli kirjoitettu editorilla eli oli tekstimuotoinen ja se sisälsi näytöltä otettuja copy/paste pätkiä asennuksen vaiheista.
Mitään luvattomia liitteitä siinä ei ollut eli itse tuo tekstitiedosto on jostain syystä luettu sellaiseksi.
Siellä oli tietysti tekstin joukossa "sudo sitä" ja "sudo tätä" kun se oli asennusohje Ubuntulle ja samoin niitä linkkejä, jotka näkyivät näytöllä asennuksen aikana. 
Tuo virheviesti syyttää potentiaalisista viruslinkeistä:

https://support.google.com/mail/answer/6590?hl=fi&ref_topic=7280460

mutta mitään vaarallista sieltä en löydä.
Viesti oli pelkkä editorilla kirjoitettu tekstiliite, ei tekstiä itse viestissä.
Olisi hauska kuulla Googlelta, mikä tuossa herkisti viestin estämiseen, viestiosan puuttuminen,  repullinen linkkejä,  sudo-komennot ohjeessa vai viestin Aihe: Certbot?  Tuo Certbot on ohjelma joka pitää yllä sertifikaatteja palvelimella. 
Näyttää Googlen seulonta-algoritmi olevan yliherkistynyt.
Lieneekö muilla havaintoja ilmeisen perusteettomalta vaikuttavasta blokkaamisesta tai esimerkiksi blokkaamisesta kun lähettää pelkän tekstiliitteen ilman viestitekstiä?   


29
ssh-avaimet käyttöön ja password login pois kokonaan (kuten nm sanoikin jo) niin ei kysele turhia.

30
Versio 2.2 näyttäisi toimivan itselläni aivan tuoreen Mint: in kanssa, mikä versio kyseessä ?

Koodia: [Valitse]
chknodes -v
chknodes yrittää näyttää jotain hyödyllistä myös hhtp-vasteista jos käyttää -H vipua ja hostnamen nimipalvelulta kysyttynä jos käyttää -n vipua.


"nmap" (pitää asentaa erikseen) on myös nopea tapa katsoa mitkä laitteet ovat aktiivisia:

Koodia: [Valitse]
nmap -sn 192.168.1.0/24
Tuon jälkeen voi toki kysyä http-vastetta vaikka curl: in avulla:

Koodia: [Valitse]
curl -I  <jokin_ip_osoite>             ^ tuo on siis iso ii-kirjain

Yhtä hyvin sillä voi tarkistaa minkä hyvänsä webbipalvelimen tilan.

31
Hetznerin virtuaalikoneella gw osoittaa yksityiseen osoitteeseen mutta koneen ip on julkisessa osoitteessa:
Koodia: [Valitse]
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.1.1      0.0.0.0         UG    0      0        0 eth0
172.31.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
Tein pienen päivityksen "regmyip" DDNS-client skriptiin tuon takia että se tunnistaa oikein sisäverkkotilanteen (NAT).
Täältä löytyy (korvasin vanhemman version):

http://www.homelinuxpc.com/download/regmyip

32
Apachen ajaminen edustalla

Tämän kokeen ajaksi korotan itseni rootiksi:
Koodia: [Valitse]
sudo -s
Apache näyttää käynnistymisensä kun sitä ajaa edustalla käyttäen -X vipua.   Käynnistyminen tarvitsee kuitenkin joitakin ympäristömuuttujia, jotka pitää asettaa ensin.  Tarvittavat ympäristömuuttujat ovat /etc/apache2/envvars tiedostossa, jonka pystyy ajamaan.  Kannattaa kuitenkin huomata, että nuo ympäristömuuttujat pitää saada nykyiseen ympäristöön, suora ajaminen muuttaa vain käynnistetyn aliprosessin ympäristöä eikä nykyistä. Asian voit todeta ajamalla tuon tiedoston:

Koodia: [Valitse]
/etc/apache2/envvars 
ja katsomalla "env" komennolla tuloksen (mitään ei muuttunut).
Oikea keino muutta nykyistä ympäristöä on käyttää ns. "source" -menetelmää, jota voi kutsua kahdella eri syntaksilla:

Koodia: [Valitse]
source /etc/apache2/envvars 
tai "piste välilyönti" menetelmällä:
Koodia: [Valitse]
. /etc/apache2/envvars
Molemmat tekevät täysin saman asian. Tuon jälkeen voi käynnistää Apachen -X vivun kanssa ja kannattaa samalla korottaa myös virheilmoitusten tasoa "debug" -tasolle, jolloin näkee mitä Apache lataa käynnistyessään:

[Tue Feb 20 12:51:38.132462 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module access_compat_module from /usr/lib/apache2/modules/mod_access_compat.so
[Tue Feb 20 12:51:38.133114 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module alias_module from /usr/lib/apache2/modules/mod_alias.so
[Tue Feb 20 12:51:38.133486 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module auth_basic_module from /usr/lib/apache2/modules/mod_auth_basic.so
[Tue Feb 20 12:51:38.133862 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module authn_core_module from /usr/lib/apache2/modules/mod_authn_core.so
[Tue Feb 20 12:51:38.134183 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module authn_file_module from /usr/lib/apache2/modules/mod_authn_file.so
[Tue Feb 20 12:51:38.134586 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module authz_core_module from /usr/lib/apache2/modules/mod_authz_core.so
[Tue Feb 20 12:51:38.134899 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module authz_host_module from /usr/lib/apache2/modules/mod_authz_host.so
[Tue Feb 20 12:51:38.135355 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module authz_user_module from /usr/lib/apache2/modules/mod_authz_user.so
[Tue Feb 20 12:51:38.135687 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module autoindex_module from /usr/lib/apache2/modules/mod_autoindex.so
[Tue Feb 20 12:51:38.136271 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module deflate_module from /usr/lib/apache2/modules/mod_deflate.so
[Tue Feb 20 12:51:38.136635 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module dir_module from /usr/lib/apache2/modules/mod_dir.so
[Tue Feb 20 12:51:38.136961 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module env_module from /usr/lib/apache2/modules/mod_env.so
[Tue Feb 20 12:51:38.137311 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module filter_module from /usr/lib/apache2/modules/mod_filter.so
[Tue Feb 20 12:51:38.137652 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module headers_module from /usr/lib/apache2/modules/mod_headers.so
[Tue Feb 20 12:51:38.137977 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module mime_module from /usr/lib/apache2/modules/mod_mime.so
[Tue Feb 20 12:51:38.138315 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module mime_magic_module from /usr/lib/apache2/modules/mod_mime_magic.so
[Tue Feb 20 12:51:38.138658 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module mpm_prefork_module from /usr/lib/apache2/modules/mod_mpm_prefork.so
[Tue Feb 20 12:51:38.138994 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module negotiation_module from /usr/lib/apache2/modules/mod_negotiation.so
[Tue Feb 20 12:51:38.139308 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module rewrite_module from /usr/lib/apache2/modules/mod_rewrite.so
[Tue Feb 20 12:51:38.139544 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module setenvif_module from /usr/lib/apache2/modules/mod_setenvif.so
[Tue Feb 20 12:51:38.139844 2018] [so:debug] [pid 7252] mod_so.c(266): AH01575: loaded module status_module from /usr/lib/apache2/modules/mod_status.so
AH00526: Syntax error on line 243 of /etc/apache2/apache2.conf:
Invalid command 'puppua_jhgjfhkdfjhkhgfkj', perhaps misspelled or defined by a module not included in the server configuration

Tein tahallaan virheen tuonne konffaustiedostoon asian havainnollistamiseksi.

Normaalisti ajettaessa Apache käynnistää useamman prosessin (lukumäärä määritetty /etc/apache2/apache2.conf tiedostossa) mutta käynnistettäessä -X vivulla edustalle käynnistyy vain yksi prosessi.

Palvelinohjelman ajaminen edustalla on joskus hyödyllinen keino selvittää ongelmallisia tilanteita. Siksi hyvin monessa palvelinohjelmassa on jokin vipu tyyliin -X, -F, --debug, jolla sen saa jätettyä päätteeseen käyntiin ilman että se vie itsensä taustalle ajoon.

Ajon saa lopetettua päätteessä painamalla Ctrl-C.

Hieman ympäristöstä
 Jos et halua muutoksia nykyiseen ympäristöön, voit aina käynnistää testailua varten uuden ympäristön (joka on nykyisen ympäristön kopio) yksinkertaisesti komennolla:
Koodia: [Valitse]
bash
ja ajaa kokeet. Lopuksi kun annat komennon:
Koodia: [Valitse]
exit 
olet taas alkuperäisessä ympäristössä (missä alkuperäiset ympäristömuuttujat).   Mikä juju tuossa sitten on?  Uusi ympäristö on kopio nykyisestä ja sisältää KOPIOT nykyisistä ympäristömuuttujista. Tämä kopioympäristö hävitetään, kun siitä palataan exit -komennolla alkuperäiseen (=edelliseen) ympäristöön. Kopioympäristössä tehdyt muutokset häipyvät etkä voi mitenkään sotkea kopioympäristössä alkuperäisen ympäristön muuttujia.
Kuten monet muistavat, ympäristömuuttujat näkee komennolla:
Koodia: [Valitse]
envKomennon antamassa listauksessa isoilla kirjaimilla kirjoitetut ovat muuttujien nimiä ja onmerkin jälkeinen osa on muuttujalle annettu arvo.  Minkä hyvänsä ympäristömuuttujan arvon voi helposti tarkastaa echo -komennolla, dollarimerkki tarvitaan silloin eteen, esimerkiksi USERNAME:
Koodia: [Valitse]
echo $USERNAME root
Ympäristömuuttuja luodaan "export" komennolla ja hävitetään "unset" komennolla:
Koodia: [Valitse]
export KISSA=valkoinen
Koodia: [Valitse]
echo $KISSA
valkoinen
(Tarkasta myös "env" komennolla, että meni ympäristömuuttujaksi eikä jäänyt vain tavalliseksi muuttujaksi. Ympäristömuuttuja periytyy lapsiympäristölle, tavallinen muuttuja ei. )
Koodia: [Valitse]
unset KISSA
Koodia: [Valitse]
echo $KISSA

33
Tänne ketjuun kannattaa jatkaa perään Apachen asennukseen tai ylläpitoon liittyviä juttuja, jotka voi säästää vaivaa ja ongelmia seuraavalla kerralla.
Avaanpa tämän heti tuoreen asennuksen yhteydessä vastaan tulleella kummallisuudella.
Asennettu oli "apache2" ja "php7.0"+ jotain tuohon liittyneitä lisukkeita.  Tuloksena oli käynnistymätön Apache ja virheissä näkyi tämmöistä:
Lainaus
There is more than one MPM loaded. Do not proceed due to undefined results
ERROR: Module mpm_ does not exist!
apache2_switch_mpm Switch to prefork failed. Rolling back to
ERROR: Could not switch to prefork MPM, not enabling PHP 7.0
Koodia: [Valitse]
sudo a2dismod
näytti, että kaksi erityyppistä mpm-modulia oli määritetty käynnistymään:
Lainaus
Your choices are: access_compat alias auth_basic authn_core authn_file authz_core authz_groupfile authz_host authz_user autoindex cgi deflate dir env filter mime mime_magic mpm_event mpm_prefork negotiation php7.0 reqtimeout rewrite setenvif status
eli mpm_event ja mpm_prefork.
Poistin tuolta mpm_event: in ja jätin mpm_preforkin.

Seuraavaksi tarkistus, joka kannattaa tehdä aina konffausmuutosten jälkeen ennen uudelleen käynnistystä:

Koodia: [Valitse]
sudo apache2ctl configtest
Lainaus
AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/conf.d/virtual.conf:2
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message

Nuo ovat normaaleja viestejä, eivät estä käynnistymistä. 

Koodia: [Valitse]
sudo service apache2 start... ja käynnissä oli.

Tein virtuaalidomaini määritykset tuossa vaiheessa ja kopioin datat toiselta koneelta.   Testiä käyntiin, mutta jotain oli merkillisellä tavalla pielessä tällä uudella koneella:  Webbiselaimella tuli vuoroon 404 File not found ja taas sivu löytyi ok.   Testasin curl: in avulla seuraavaksi, tältä se näytti vuoroon aivan miten sattui:
Lainaus
HTTP/1.1 404 Not Found
Date: Mon, 19 Feb 2018 16:53:41 GMT
Server: Apache/2.4.18 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1
Lainaus
HTTP/1.1 200 OK
Date: Mon, 19 Feb 2018 16:53:39 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Fri, 08 Mar 2013 08:52:20 GMT
ETag: "1a45-4d765f0e43900"
Accept-Ranges: bytes
Content-Length: 6725
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8

Oli ideat aika vähissä, miksi asennus toimi 2 muulla Apache-koneella ok, mutta tämä uusi reistaili.   Näkyvää syytä ei löytynyt aivan pienellä vaivalla. Apache oli tismalleen sama versio kuin toimivassa kokoonpanossa, konffaukset oli kopioitu toisesta asennuksesta.  "a2dismod" näytti, että kaikki ladatut modulit pitäisi olla samoja.  Huomiota kiinnitti pieni sivuseikka:  Apache tunkee väkisin virheet tuossa iso-8859-1 muodossa vaikka muuten toimii UTF-8 asetuksilla.  Tuo on ilmeisesti Apachen ominaisuus/omituisuus, johon en löytänyt lääkettä:

https://stackoverflow.com/questions/20283301/set-charset-in-errordocument-messages

Jäljille johti yksi havainto, mitähän ajattelet tästä:

Koodia: [Valitse]
sudo service apache2 stop
root@Web01:/etc/apache2# pgrep apache
3575
3578
3579
 
Koodia: [Valitse]
ps -ef | grep -i apache
root      1682 31370  0 20:04 pts/0    00:00:00 grep --color=auto -i apache
root      3575     1  0 12:51 ?        00:00:02 /usr/sbin/apache2 -k start
www-data  3578  3575  0 12:51 ?        00:00:13 /usr/sbin/apache2 -k start
www-data  3579  3575  0 12:51 ?        00:00:13 /usr/sbin/apache2 -k start

Käynnissä oli prosesseja, jotka eivät olleet hallinnassa. En ala arvaamaan tarkemmin, mistä nuo olivat jääneet mutta viittaa vahvasti silti siihen alkutilanteeseen useammasta mpm-modulista.

Koodia: [Valitse]
sudo killall apache2
sudo service apache2 start

Kaikki kunnossa eikä enää puolet ajasta 404 sivuja.








34
Joo, Samsungeja on parikin kappaletta ollut jo pitkään. Merkillistä on se, että oheisen kuvan mukaan oletettavissa olevaan tapahtuma-aikaan 20:08 en ollut missään tekemisissä Samsungin kanssa vaan ajoin dovecot-core pakettia koneeseeni tarkoituksella käyttää siitä vain yhtä ohjelmaa (doveadm) ja koodata salasanoja sillä.  Poistin paketin ja laitoin uudestaan, mitään erikoista ei kuitenkaan sattunut.

35
En ole varma, mikä sekoitti /usr haaran omistuksen kotikoneellani merkillisille lukemille 8070:9999. Jäljet näytti jatkuvan "libtiff.so" suuntaan.  Ilmiön havaitsin välittömästi dovecot-core asennuksen jälkeen, mutta se ei välttämättä liity siihen mitenkään.  Viimeisimmät Ubuntu-päivitykset ajoin juuri äskettäin.  Näin se eteni:
- Palomuuri UFW nimittäin heitti herjan, että /usr väärässä omistuksessa.   
- Tarkastin, niinpä olikin tilanne ja monta muutakin asiaa oli 8070:9999 omistuksessa.
- Lääkkeeksi  sudo chown -R root:root /usr
- Hups, mitäs nyt?   Nyt ei sudo enää toimi!
Koodia: [Valitse]
sudo: polun /usr/bin/sudo omistajan on oltava uid 0 ja setuid-bitin on oltava asetettu
Sillä lailla.  Ei ollut mitään keinoa päästä rootiksi enää.   Piti käynnistää toinen asennus rinnakkaisesta osiosta ja käydä muuttamassa levylle sudoon takaisin suid.
 Tuossa oli pieni opetus:  Tuo chown aiheuttaa sivutuotteena jostain syystä, että sudo-tiedostolta putoaa pois suid, jonka jälkeen sitä ei pysty enää käyttämään.  Lääke siihen on tietty laittaa se takaisin (kayttäen eri osiosta käynnistettyä Linuxia ellet ole roottina toisessa päätteessä): 
Koodia: [Valitse]
sudo chmod 4755 /usr/bin/sudoTarkastin vielä erikseen toisen kerran, että siinä käy noin.  Jätin toki itseni rootiksi toisessa päätteessä, että pääsin heti korjaamaan.

Seuraavaksi yritin sammuttaa Mysql: n, eipä sammunut vaan komento jäi roikkumaan.  Tuo ongelma oli ilmestynyt aamun jälkeen, kun ajoin viimeisimmät päivitykset.

Kummallisuuksia näkyi syslogissa useitakin: apparmor oli estänyt mysql: n sammutuksen,  koneen kello oli hypähtänyt päivän aikana merkillisesti mutta syytä omistajuuden muutokseen en havainnut siellä.

Koodia: [Valitse]
Feb 17 23:14:38 ESPRIMO-P3521 kernel: [   26.612371] audit: type=1400 audit(1518902078.106:15): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/1174/status" pid=1174 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=123 ouid=123

Mielenkiintoinen ilta.   Varsinainen puuhani Postfix+Dovecot autentikointijutut (CRAM-MD5) jäivät hetkeksi lepäämään. Näkyy muuten erikoinen aika tuossa logissa. Koneen kello näyttää kuitenkin oikeaa aikaa juuri nyt.
 

36
Itse olen ripustanut ulkoisen USB-levyn koneeseen ja käyttänyt "rsnapshot" ohjelmaa.  Toimii ajastetusti taustalla ja tekee helposti palautettavaa rakennetta. Pääsee ajassa taakse päin päivittäin, viikottain tai kuukausittain. Halutessaan tiiviimminkin, vaikka tunnin välein kun tekee asetukset sen mukaisiksi. 

37
Olen päivittänyt kaikista niistä varoitteluista huolimatta ja näytti toimivan ok.

38
Ubuntu tietokoneissa / Vs: HP tulostin ongelma
« : 10.11.17 - klo:00.47 »
Eikös siellä ollut Wireless Setup / PIN vaihtoehto, tuohon kun syöttää sen reitittimen salasanan niin sen pitäisi yhdistyä.

Vähän vaikea arpoa näin etänä, mutta joissakin muissa HP-malleissa se ainakin oli asetettavissa käsin tuosta kirjoittimen paneelista.

Sen jälkeen kun langaton yhteys onnistuu, niin jokin hpsetup tms. (en muista nimeä tarkemmin) löytää sen. 

39
Ubuntu tietokoneissa / Vs: HP tulostin ongelma
« : 07.11.17 - klo:21.51 »
Näkemättä kirjoitinta arvaan, että siinä olisi mahdollisuus laittaa wlan-asetukset sen kirjoittimen omasta paneelista?

40
Kannattaa ehkä vilkaista

Koodia: [Valitse]
route -n

Sivuja: 1 [2] 3 4 ... 169