Linux-haladó

Security Warning: these home directory should not be owned by someone else or writable :
user=davfs2(982) : home directory is group writable.

No de: 

A .davfs mappa 700-as a fájlok 600-as engedélyűek. 

$ ll .da*
összesen 56
drwx------ 3 nextra nextra  4096 dec    3  2017 cache/
drwxr-xr-x 3 nextra nextra  4096 aug    8  2016 certs/
-rw------- 1 nextra nextra  2167 ápr   14  2014 davfs2.conf
-rw------- 1 nextra nextra  2705 aug    8  2016 secrets

Sziasztok!

Alapbol utalok hiv. tarolokon kivuli cuccokat telepiteni, "tisztan" .deb-et meg megjobban... Minden progim vagy az adott distro sajat tarolojabol jon, vagy az app sajat tarolojabol. Most viszont egy fuggoseg miatt "rakenyszerultem", hogy .deb bol telepitsek ket progit, mivel az ubuntu 20.04 tarolojaban mar egyik sincs benne.

libffi6 (19.10-es tarolobol letoltve)

libreadline7 (18.04-es tarolobol letoltve)

Ilyenkor mi a legjobb a mod ezen csomagok karbantartasara? Irjam fel valahova, hogy ne felejtsem el es ennyi? Nincs a 20.04-nek valami taroloja, ahol esetleg fonn vannak meg ezek a csomagok? (en nem talaltam, de hatha ti tudtok valami titkos tarolorol :) )

Why linux is not ready for the desktop.

Nagyon érdekes és objektív pontok. Mi a te véleményed?

Van ennél kényelmesebb, felhasználóbarátabb mód arra, hogy működő Windows alól be lehessen állítani, hogy következő reboot után másik OS, például Linux bootoljon be default rendszerként?

Természetesen egy dual-boot gépen.

A cím kicsit pongyola. De szeretném, hogy amikor ráklikkelnek a Leállításra, akkor még mielőtt az egész procedúra elkezdődik, lefutna egy program. Ezért azt a szkriptet melynek le kéne futnia, beletettem az /usr/lib/systemd/system-shutdown mappába shutdown kiterjesztéssel.. Viszont nem történt semmi.

Készítettem egy teszt fájlt, mely csak annyit tesz hogy 3 percig várakoztatja a gépet a kikapcsolás előtt. Ugyanide tettem, és az meg működik. Arra jutottam, hogy a szkript lefut ugyan, de a /dev/null-ban. Fogjuk rá hogy jó helyen van, de a legutolsó a sorban, holott a legelsőnek kellene lennie. Magyarul az ide berakott szkriptek melyeknek talán még fájlműveleteket is kellene folytatniuk, nem fognak működni, mert eddigre (addigra?) már lecsatolódott a fájlrendszer, kiléptek a felhasználók, és ennyi.

Jó, akkor jöjjön a service. Készítettem egyet, mely meghívta a szkriptemet, de ugyanez lett a jelenség. Nem történt semmi. Nos. Most ott tartok, hogy meg kell határoznom, melyik service után fusson le.

Jól gondolom-e hogy ez talán disztrófüggő? Ha pl. megadom hogy After=local-fs.target, akkor le is késtem a dologról, mert lecsatolta a fájlrendszert. No de akkor mi után? Azt egyelőre nem tudom hogy miként fedezzem fel, az egyes service folyamatok sorrendjét kikapcsolás esetén. Van erre valami lehetőség, vagy ötletek, hogy mit állítsak be?

Az én rendszerem nem használ sudo parancs szisztémát. Nem mintha most szeretnék váltani. root felhasználó létezik. Ennek ellenére ha szükség van rá, szerkeszthető a sudoers fájl a visudo-val hogy akár a felhasználó kezébe adjunk root jogokkal futó programnak a végrehajtását. Akkor most van a gépemen SUDO vagy nincs? 

Szükségem lenne a felhasználó kezébe adni az rtcwake parancsot. Manuálisan megszerkesztve a sudoers fájlt ez megoldható. No de ott van az /etc/sudoers.d mappa.
Nem lenne egyszerűbb abba beletenni a kívánt dolgot?

Létrehoztam egy új csoportot, mely eddig nem létezett. kikapcs lett a neve. usermod -G kikapcs felhasználó 
Erre azért volt szükség mert a felhasználó nevében szkript fog futni és a szkriptnek ki kell kapcsolni a gépet ha úgy alakul akkor is, ha történetesen a felhasználó nincs is bejelentkezve. Működik.

Viszont a felhasználónak be kell tudnia állítani azt is, hogy a gép bekapcsoljon adott időben magától. Erre a feladatra használhatja az rtcwake parancsot. De jelenleg ezt csak a root tudja futtatni. Ez még BIOS-os gép.

Mint említettem a sudoersben ez beállítható. De egyszerűsíteném a dolgot. Létrehoztam az /etc/sudoers.d mappában egy 99-bekapcs,conf fájlt. Amiben ez van:

Defaults:felhasználó_neve !requiretty 
%kikapcs ALL = NOPASSWD: /usr/sbin/shutdown, /usr/sbin/rtcwake

De nem működik. Ez azért van mert nem sudo-s a rendszerem? Vagy ez nem is fog soha? Nem gond, csak szeretném megérteni. Amúgy ez Mageia LInux.
Ha ugyanezt beírom visudoval, akkor működik. Ráadásul a sudoers fájl végén ott van hogy #includedir /etc/sudoers.d (A # jel itt nem commentet takar.)
 

Milyen alternatívái vannak a Teamviewer, Chrome remote desktop -nak? 

Amit tudnia kell:

- Szinte észrevehetetlen legyen a különbség, mintha az adott desktop előtt ülnék. 

- Videólejátszás tökéletesen működjön, kép-hang csúszás nélkül. (Nem videózásra kell de ez a sarkalatos pont. Ha ez működik akkor általában más is. Game streaminget is írhattam volna.)

- Használja ki a rendelkezésre álló sávszélességet. Azaz ne rontsa feleslegesen a desktop képminőségét amikor lokális neten rendelkezésre áll egy gigabites kapcsolat. 

- Nem kell opensourcenak lennie, de természetesen ha van az preferált. 

Amit nem kell tudnia:

- Központi szerver NAT+távoli eléréshez. Megoldom a ddns-t és portátirányítást ha az kell. Bár inkább oVPN.

Sziasztok!

Dockerben fut a Nextcloud már jó pár hónapja az alábbi hiba(?)jelenség nélkül.
4-5 napja felfigyeltem, hogy ütemesen írja valami a merevlemezt apróbb szünetekkel (kb. 0,5 mp írás és 0,2 szünet, ritkán akár 1-2 perc nyugalom, majd előröl) elég zavaró. Először merevlemezhibára gyanakodtam, de erre a kernel logban nem találtam utalást. Aztán iotop alapaján egy mysqld processz látszott ludasnak, ami a containerd szálában van. Kis keresgélés után megtaláltam, hogy docker nextcloud-mariadb imagehez tartozik.
Hogy egyértelműen be lehessen azonosítani, jelenség a
 

docker stop nextcloud-mariadb

parancsra megszűnik. Majd a start után ismét jelentkezik. Szóval, a ludas egyértelműen megvan.
Frissítettem időközben Nextcloud 17-ről 18-ra, a jelenség nem szűnt meg. Frissítettem az OS-t Lubuntu 19.10-ről 20.04-re (ezzel a containerd.io is frissült), de a jelenség továbbra is fennáll.
Vagy ügyetlenül kerestem, hogy másnál is előfordult-e, esetleg van-e rá megoldás, egyébként is mi okozza... De sajnos nem találtam.
Ha esetleg valamelyikőtök tapasztalt már ilyet, és sikerült elhárítani, örömmel venném, ha tudna segíteni.
Esetleg van-e ötletetek, hogy magában a mysql táblában mit próbáljak tenni, ha felmerül a gyanútok, hogy ez valami tábla hiba lesz?
Az mysgl promptot (mariadb) IP alapján elérem:
 

mysql -uroot -pJelszavam -h 172.18.0.4 -P 3306

A docker image-be bash-sal beléptem 

mysqlcheck --check --use-frm --all-databases -p 

a rendben lefutott, a --repair dobott warningokat, hogy egyes táblák nem támogatják a repairt, de hibát nem talált.
 

Előre is köszönöm a segítségeket.

Redhat 7-es rerndszer, pam_tally konfigolva user kitiltasara (password-auth):

-----------------

auth        required      pam_env.so
auth        required      pam_tally2.so onerr=fail deny=3 unlock_time=180 even_deny_root
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so
...

-----------------

A gond az, ha nyitok egy X kepernyot (Gnome alatt) es bejon a kepernyokimelo, majd nyomok egy gombot, elojon a lockscreen kijelzo, majt itt 3x sima ESC gombot nyomok, a rendszer kitilt. Azaz emeli a pam_tally counter-t.

Ugy nez ki, a gdm-password felel ezert, ez igy nez ki:

-----------------

auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth        substack      password-auth
auth        optional      pam_gnome_keyring.so
auth        include       postlogin

...
------------------

Ez lenne a cel, hogy az ESC megnyomasok ne eredmenyezzenek "failed login attempt" uzenetet, azaz csak akkor tiltson ki a tally, ha tenyleg rossz jelszot irtam be.

Otlet?

(a sima pam_tally -nak benn kell maradnia a rendszerben, mas service is hasznalja)