Linux-haladó

Sziasztok

Adott 2 proxy (proxy1 es proxy2) mindkettő apache2

ez a két proxy sorba van kötve.

Tűzfal->Proxy1->Proxy2->BackEnd{1..n}

A proxy1-en meg van adva, hogyha nem éri el proxy2-t, akkor ő forduljon a BackEnd-ekhez.

# Proxy 2
BalancerMember http://10.0.1.2:80 ttl=15 timeout=2
# BE
BalancerMember http://10.0.2.101:8080 ttl=15 timeout=50 max=8 status=+H
BalancerMember http://10.0.2.102:8080 ttl=15 timeout=50 max=8 status=+H

ProxyPass / balancer://myclu/
ProxyPassReverse / balancer://myclu/

A proxy2 -n:

# BE
BalancerMember http://10.0.2.101:8080 ttl=15 timeout=50 max=8 status=+H
BalancerMember http://10.0.2.102:8080 ttl=15 timeout=50 max=8 status=+H

ProxyPass / balancer://myclu/
ProxyPassReverse / balancer://myclu/

mindkettőn be van állítva: ProxyPreserveHost On

he lekérdezek a proxy1 -be, hogy adja ki az oldalt, akkor a linkeknél nem http://10.0.1.1/valami (a proxy1 címe) hanem a backend címe látható: http://10.0.2.101:8080/valami

ha kiveszem belőle a proxy2-t mint lekérdezési lehetőséget, akkor rendesen a backend címei helyett a proxy1 címe látható a linkekben.

Feltétlenül szükséges a proxy1 mögé a proxy2.
Mit kell még beállítani hogy úgy működjön ahogy kellene?

Sziasztok, Tud valaki valamilyen megoldást hogyan lehetne használni ACL-t NFS megosztáson, egyáltalán kivitelezhető? Igazából amit találtam ezzel kapcsolatban nem valami részletes. Van egy szerverem ami AD-ből autentikálja az felhasználókat és egy NFS megosztásra írnának, amit egy NAS-ból van felcsatolva. De ha ACL akarok beállítani akkor hibára fut.
setfacl: /megosztas: Operation not supported

hello

van egy xen guest gép ahol a xen-create-image ugye csak partíciókat hozott létre (/ és swap) a gépnek. A root partíciót növelném

dd if=/dev/zero of=sparse.img bs=1M count=0 seek=1024

de a teszt gépen ahol próbálom nem tudom újra szkennelni a partíciót ahogy a echo "- - -" > /sys/class/scsi_host/host0/scan parancs tenné.

van valakinek ötlete, hogy hogyan lehet ezt kivitelezni?

Kedves kollégák! Érdeklődnék, hogy tudományos fejlesztési célokra fizikus hallgatónak milyen disztribúciót ajánlotok. Elsősorban a C/C++ és python programozás sok matekkal, haladó felhasználó számára.

A válaszokat előre is köszönöm.

Sziasztok,
van egy odroid xu4 gépem. Erre tettem egy armbian-t cli debian 9-essel. Kapott egy ligthdm-et, egy xorg-ot, és egy kodi-t. A lightdm automatikusan belogoltat, majd indítja a kodit. Viszont elég sok erőforrás elmegy. Elvileg simán vinnie kellene. Valami hw mintha nem lenne fent. Ezt hogyan tudom ellenőrizni? Már maga a kodi szaggat, nem is kell hogy fusson valami videó.
Elvileg ezek között kellene lennie, de nem megy.
https://wiki.debian.org/MaliGraphics
https://packages.debian.org/search?keywords=mali

Sziasztok!

Kb 1 hónapja használjuk mentésre a BareOS backup rendszert.
Eddig nagyrészt jól teljesít, de van egy hiba ami most jött elő és nem tudom mi okozhatja:
A director egyik pillanatról a másikra megáll ezzel megállítva a mentési mechanizmust.
Elindítva megy szépen tovább...

Körülmények:
- Akkor szokott megállni, ha tele van az összes "mentési kazetta" és emiatt hosszú ideig vár.
- Akkor szokott még megállni ha tele van az összes "mentési kazetta" és cserélnie kell egy olyan dátumura ami már lejárt.

A mentések fájlba készülnek, tehát a "mentési kazetta" nálam egy fájlt jelent.

Remélem lesz ötlet a megoldásra, mert ez egy elég szimpatikus rendszer ennek ellenére is! :)

https://downloads.openwrt.org/releases/

Tud valaki olyan "oneliner"-t (foleg bash), amely kernel crash-t okoz Linuxok alatt, de "aranylag" biztonsagos, azaz nem ir at fontos memoriateruleteket, amely FS (vagy barmi mas) inkonzisztenciat okozhat?

Sziasztok!

Adott egy VNC szerveren belül futó Windowsos alkalmazás ami egy Debian 9-en fut Wine segítségével. Ezt az alkalmazást Bármilyen VNC klienssel el lehet érni (Remmina, RealVNC, stb…)
Azt vettem észre, hogy ha az adott alkalmazás VNC képernyőjén túl sok minden történik akkor megugrik a CPU terhelése (akkor is ha nincs bejelentkezve senki se VNC-n). Ha viszont az alkalmazást leteszem tálcára akkor a CPU használat elhanyagolható. Ezért kitaláltam azt, hogy ha X ideig nem lépnek be a VNC-re akkor automatikusan tegye le tálcára az alkalmazást. Ezzel a szerver magasabb CPU terhelése nagyjából csak annyi ideig tart amíg aktívan használják a programot. Azt már tudom cronból figyelni, hogy mikor vannak belépve a VNC-re és mikor nem. Arra viszont nincs ötletem, hogyan és milyen módon történjen automatikusan a beavatkozás a VNC-n belül futó programon.

Van erre ötletetek?

Kedves Fórumozók!

5-6 éve építettem magamnak pár guide (1, 2) alapján, akkor még SlackwareARM 14.1 alapokon.
Mivel az a verzió már egy ideje EOL, így gondoltak itt lenne az ideje átállni a még támogatott 14.2-es verzióra. (A SlackwareARM -current-je nem működik már Raspberry PI 1-gyel.)

A konstrukció (egy GPS vevővel és elvezetett PPS erekkel) egészen jól működött eddig, azonban most az újratelepítés után látszólag nem működik a gpsd által átadandó idő, az ntpd-ben.
Annyi kiegészítés még szükséges, hogy az ntpd-t forrásból kell újraforgatnom, hogy legyen benne pps támogatás (--enable-ATOM), és a gpsd-t is nekem kellett fordítani. A PPS jel a GPS modulból jön, a szükséges kernel támogatás révén, a /dev/pps0 eszközfájlon keresztül, amit az ntpd közvetlenül használ.
Hogy miről is beszélek, íme az ntpd konfiguráció egy része:

# pps-gpio on /dev/pps0
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag3 1 refid PPS  # enable kernel PLL/FLL clock discipline
# gpsd shared memory clock
server 127.127.28.0 minpoll 4 maxpoll 4 noselect
fudge 127.127.28.0 time1 0.000 flag1 1 refid GPSD stratum 15

#
# NTP server (list one or more) to synchronize with:
server ntp0.as34288.net minpoll 5 maxpoll 5 iburst prefer
server clock1.infonet.ee minpoll 5 maxpoll 5 iburst prefer
server ntps1-0.cs.tu-berlin.de minpoll 5 maxpoll 5 iburst
pool hu.pool.ntp.org minpoll 5 maxpoll 5 iburst
server 0.hu.pool.ntp.org minpoll 5 maxpoll 5 iburst
server 1.hu.pool.ntp.org minpoll 5 maxpoll 5 iburst
server 2.hu.pool.ntp.org minpoll 5 maxpoll 5 iburst
server 0.ru.pool.ntp.org minpoll 5 maxpoll 5 iburst
server 0.de.pool.ntp.org minpoll 5 maxpoll 5 iburst

Ez pedig az ntpq parancs kimenete:

root@ntp:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.22.0    .PPS.            0 l   12   16  377    0.000    0.011   0.004
 127.127.28.0    .GPSD.          15 l    -   16    0    0.000    0.000   0.000
 hu.pool.ntp.org .POOL.          16 p    -   32    0    0.000    0.000   0.004
*81.94.123.16    85.158.25.74     2 u   10   32  367   32.317    1.183   1.443
+212.7.1.131     .PPS0.           1 u    9   32  377   48.174    7.849   1.044
+130.149.17.21   .PPS.            1 u   15   32  377   39.092    2.429   1.243
-62.112.193.9    193.225.126.78   3 u    7   32  377   10.028    5.069   1.442
-82.141.152.3    193.6.222.47     3 u   25   32  377   15.423    2.445   1.565
+62.112.195.26   84.2.44.19       3 u   21   32  377    9.841    2.985   1.730
-85.21.78.8      89.109.251.21    2 u   12   32  377   66.787    5.531   0.833
+94.130.184.193  192.53.103.104   2 u   16   32  377   29.090    3.722   0.357

Ahogy látszik, az GPSD-s időforrás reach értéke 0, vagyis az ntpd-nek egyszer sem sikerült lekérdeznie.
A gpsd láthatóan fut, és szolgáltatja azokat az osztott memóriablokkokat (shared memory) ahonnan az ntpd le tudná kérdezni.
Meglepő módon az ntp meg is nyitja az egyik ilyen blokkot, de a reach ennek ellenére 0.

root@ntp:/usr/src# cat /etc/default/gpsd 
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true"
GPSD_OPTIONS=""
DEVICES="/dev/ttyAMA0"
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"
root@ntp:/usr/src# ps auxfw | grep -E "(ntp|gps)d"
nobody   31990  0.0  0.5   4756  2768 ?        S<s  jan26   0:00 /usr/local/sbin/gpsd -P /var/run/gpsd.pid -F /var/run/gpsd.sock /dev/ttyAMA0
root     32229  0.0  0.8   7612  4296 ?        Ss   jan26   0:37 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
root@ntp:/usr/src# ipcs -m

------- Osztott memóriaszegmensek --------
kulcs      o.m.-az    tulajdonos jogok      bájt      csat.szám állapot    
0x4e545030 0          root       600        80         2                       
0x4e545031 32769      root       600        80         1                       
0x4e545032 65538      root       666        80         1                       
0x4e545033 98307      root       666        80         1                       
0x4e545034 131076     root       666        80         1                       
0x4e545035 163845     root       666        80         1                       
0x4e545036 196614     root       666        80         1                       
0x4e545037 229383     root       666        80         1                       
0x47505344 262152     root       666        8928       1                       
root@ntp:/usr/src# lsof | grep gpsd
gpsd      31990         nobody  cwd       DIR      179,3     4096          2 /
gpsd      31990         nobody  rtd       DIR      179,3     4096          2 /
gpsd      31990         nobody  txt       REG      179,3   450664     187572 /usr/local/sbin/gpsd
gpsd      31990         nobody  mem       REG      179,3    51948      39099 /lib/libnss_nis-2.23.so
gpsd      31990         nobody  mem       REG      179,3    97804      39096 /lib/libnsl-2.23.so
gpsd      31990         nobody  mem       REG      179,3    41152      39097 /lib/libnss_compat-2.23.so
gpsd      31990         nobody  mem       REG      179,3    47972      39098 /lib/libnss_files-2.23.so
gpsd      31990         nobody  mem       REG      179,3   122012         61 /lib/libudev.so.1.6.3
gpsd      31990         nobody  mem       REG      179,3  1624056      39100 /lib/libc-2.23.so
gpsd      31990         nobody  mem       REG      179,3   131264      10577 /lib/libpthread-2.23.so
gpsd      31990         nobody  mem       REG      179,3   258196     131860 /usr/lib/libdbus-1.so.3.14.6
gpsd      31990         nobody  mem       REG      179,3    37008      10579 /lib/librt-2.23.so
gpsd      31990         nobody  mem       REG      179,3   725028      10566 /lib/libm-2.23.so
gpsd      31990         nobody  mem       REG      179,3   124484     194676 /usr/lib/libbluetooth.so.3.18.16
gpsd      31990         nobody  mem       REG      179,3    78052     130400 /usr/lib/libusb-1.0.so.0.1.0
gpsd      31990         nobody  mem       REG      179,3   163624      39124 /lib/ld-2.23.so
gpsd      31990         nobody  DEL       REG        0,5              262152 /SYSV47505344
gpsd      31990         nobody  DEL       REG        0,5              229383 /SYSV4e545037
gpsd      31990         nobody  DEL       REG        0,5              196614 /SYSV4e545036
gpsd      31990         nobody  DEL       REG        0,5              163845 /SYSV4e545035
gpsd      31990         nobody  DEL       REG        0,5              131076 /SYSV4e545034
gpsd      31990         nobody  DEL       REG        0,5               98307 /SYSV4e545033
gpsd      31990         nobody  DEL       REG        0,5               65538 /SYSV4e545032
gpsd      31990         nobody  DEL       REG        0,5               32769 /SYSV4e545031
gpsd      31990         nobody  DEL       REG        0,5                   0 /SYSV4e545030
gpsd      31990         nobody    0u      CHR        1,3      0t0       4426 /dev/null
gpsd      31990         nobody    1u      CHR        1,3      0t0       4426 /dev/null
gpsd      31990         nobody    2u      CHR        1,3      0t0       4426 /dev/null
gpsd      31990         nobody    3u     unix 0xdc0ce4c0      0t0     198706 /var/run/gpsd.sock type=STREAM
gpsd      31990         nobody    4u     IPv4     198709      0t0        TCP localhost:2947 (LISTEN)
gpsd      31990         nobody    5u     IPv6     198710      0t0        TCP [::1]:2947 (LISTEN)
gpsd      31990         nobody    6u     unix 0xdc0ce980      0t0     198711 type=STREAM
root@ntp:/usr/src# lsof | grep ntpd
ntpd      32229           root  cwd       DIR      179,3     4096         12 /root
ntpd      32229           root  rtd       DIR      179,3     4096          2 /
ntpd      32229           root  txt       REG      179,3   638344     187641 /usr/sbin/ntpd
ntpd      32229           root  mem       REG      179,3   101416      10578 /lib/libresolv-2.23.so
ntpd      32229           root  mem       REG      179,3    26040      10571 /lib/libnss_dns-2.23.so
ntpd      32229           root  mem       REG      179,3    47972      39098 /lib/libnss_files-2.23.so
ntpd      32229           root  mem       REG      179,3   124816     130416 /usr/lib/libgcc_s.so.1
ntpd      32229           root  mem       REG      179,3    13936      39101 /lib/libdl-2.23.so
ntpd      32229           root  mem       REG      179,3  1624056      39100 /lib/libc-2.23.so
ntpd      32229           root  mem       REG      179,3   131264      10577 /lib/libpthread-2.23.so
ntpd      32229           root  mem       REG      179,3  1743724      10721 /lib/libcrypto.so.1.0.0
ntpd      32229           root  mem       REG      179,3   390668      10722 /lib/libssl.so.1.0.0
ntpd      32229           root  mem       REG      179,3   725028      10566 /lib/libm-2.23.so
ntpd      32229           root  mem       REG      179,3    14600         77 /lib/libcap.so.2.22
ntpd      32229           root  DEL       REG        0,5                   0 /SYSV4e545030
ntpd      32229           root  mem       REG      179,3   163624      39124 /lib/ld-2.23.so
ntpd      32229           root  mem       REG      179,3    14028         65 /lib/libattr.so.1.1.0
ntpd      32229           root    0r      CHR        1,3      0t0       4426 /dev/null
ntpd      32229           root    1r      CHR        1,3      0t0       4426 /dev/null
ntpd      32229           root    2r      CHR        1,3      0t0       4426 /dev/null
ntpd      32229           root    3u     unix 0xdc0cf0a0      0t0     199471 type=DGRAM
ntpd      32229           root    4u      CHR      244,0      0t0       6243 /dev/pps0
ntpd      32229           root   16u     IPv6     199476      0t0        UDP *:ntp 
ntpd      32229           root   17u     IPv4     199479      0t0        UDP *:ntp 
ntpd      32229           root   18u     IPv4     199484      0t0        UDP localhost:ntp 
ntpd      32229           root   19u     IPv4     199486      0t0        UDP ntp.lan:ntp 
ntpd      32229           root   20u     IPv6     199488      0t0        UDP [::1]:ntp 
ntpd      32229           root   21u     IPv6     199490      0t0        UDP [fe80::ba27:ebff:fe97:56b7]:ntp 
ntpd      32229           root   22u  netlink                 0t0     199491 ROUTE
root@ntp:/usr/src#

Ahogy láthattuk fentebb, az ntpd root-ként fut, és ennek ellenére az egyik osztott memóriaterületre reject-et kapott a hozzáférési kísérlete. (Legalábbis szerintem ezt jelentik ez a kimenet.)

root@ntp:/usr/src# ntpq -c peer -c as -c rl
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    4   16  377    0.000    0.008   0.004
 SHM(0)          .GPSD.          15 l    -   16    0    0.000    0.000   0.000
 hu.pool.ntp.org .POOL.          16 p    -   32    0    0.000    0.000   0.004
*ntp0.as34288.ne 85.158.25.74     2 u   11   32  377   32.965    1.413   1.389
+clock1.infonet. .PPS0.           1 u    4   32  377   48.560    7.746   1.775
+ntps1-0.eecsit. .PPS.            1 u   17   32  377   38.581    2.312   2.727
-quaen.fradi.hu  193.225.126.78   3 u    9   32  377   10.509    4.858   1.932
-www.kapos-net.h 193.6.222.47     3 u   26   32  377   15.126    1.992   2.301
+zearla.netinfor 84.2.44.19       3 u   24   32  377   10.268    3.051   2.964
-ftpshare1.corbi 192.36.133.17    2 u   14   32  377   67.035    5.796   1.155
+nbg01.muxx.net  192.53.103.104   2 u   14   32  377   28.883    3.459   1.729

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 38258  973a   yes   yes  none  pps.peer    sys_peer  3
  2 38259  802b   yes    no  none    reject clock_alarm  2
  3 38260  8811   yes  none  none    reject    mobilize  1
  5 38262  963a   yes   yes  none  sys.peer    sys_peer  3
  6 38263  9424   yes   yes  none candidate   reachable  2
  7 38264  9424   yes   yes  none candidate   reachable  2
  8 38265  9324   yes   yes  none   outlier   reachable  2
  9 38266  933a   yes   yes  none   outlier    sys_peer  3
 10 38267  9424   yes   yes  none candidate   reachable  2
 11 38268  9324   yes   yes  none   outlier   reachable  2
 12 38269  9424   yes   yes  none candidate   reachable  2
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p8@1.3265-o Sun Jan 20 17:03:24 UTC 2019 (1)",
processor="armv6l", system="Linux/4.14.56-arm", leap=00, stratum=1,
precision=-18, rootdelay=0.000, rootdisp=1.090, refid=PPS,
reftime=dff86594.2c7b2bc0  Sun, Jan 27 2019 18:15:00.173,
clock=dff8659a.c9727f7c  Sun, Jan 27 2019 18:15:06.786, peer=38258, tc=4,
mintc=3, offset=0.008282, frequency=-60.195, sys_jitter=0.003815,
clk_jitter=0.004, clk_wander=0.002
root@ntp:/usr/src#

Próbáltam már pár kört google-özni a probléma megoldása végett, de egyik ötlet sem segített:

• flags1 1-re állítása
• az ntpd-t futtató user ellenőrzése (másutt nem root-ként fut, így nem fér hozzá az osztott memóriához)

Most a közösséghez fordulnék, hátha találkozott már valaki hasonló problémával.

Köszi!
János