Linux-haladó

Wine/Proton/Steam Play

Fórumok

Sziasztok!

Csak Én nem értem, hogy ez a Proton miért olyan nagy show, miért kellene ezt szeretnünk?

- Lassítja - az amúgy szépen megindult - natív játékfejlesztést. Konzerválja a Windows-os dominanciát.
- Mivel a Windows-os játékok nagyon különbözőek, ezért nehéz rájuk emulátort írni. Pl. Egy PS3ra sokkal könnyebb lenne, és valsz. értelmesebb is.
- Wine csak X alatt képes futni, a mostani irány pedig már régóta a Wayland.
- Nekem se egy Warcraft III, se egy Doom 2016 nem képes rendesen futni Wine alatt. Mindig szétfagy vagy más baja lesz.

Friss domain vs gmail

Fórumok

Sziasztok!

Rég nem regeltem domain-t azonban most egy ismerősöm megkért rá.
Egy virtuális gépre lett berakva ahol postfix kezeli. A gmail-en kívül mindenhonnan jönnek mennek a levelek. Amennyiben én írok a gmail-es címemről a levél bejön, illetve ha erre jön reply akkor automatikusan berakja a gmail a spamba. Amennyiben ez a host küld levelet, akkor 550-5.7.1 mail hibát ad a google.
A DNS rekordok lassan egy regényhez hasonlítanak, pl rakjak be google spec dns ellenőrzést TXT-be.... Az MX mellett van már spf,google-site,dmarc rekordom is.
Van erre valami megoldás? Vagy várni kell valami időt, és menni fog?

MySQL beállítása sok konkurens kéréssel

Fórumok

Sziasztok,

Az alábbi problémával fordulnék hozzátok, melyre nem találom a jól működő megoldást:
Adott egy MySQL szerver rajta egy nem túl bonyolult 100 táblás adatbázis MySQL alapon. Az adatbázist egy szoftveren keresztül 60 ember használja egyszerre. Ez alapvetően nem sok, de mégis nagyon gyakori az alábbi két hibaüzenet:
- Deadlock found when trying to get lock; try restarting transaction
- Lock wait timeout exceeded; try restarting transaction

Illetve egy ráadás üzenet, ami bár nem biztos a konkurens kérésekkel függ össze, de mégis gyakori és látszólag semmi nem indokolja:
- Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding
Az üzenet arról árulkodik, hogy gond lenne az adatbázis szerver válaszadásával, vagy elérhetetlen lenne, vagy bármi hasonló probléma. De ez nem igaz, mert a mellette ülő (programot használó) gond nélkül használja a rendszert.

Végül pedig a log fájl, amit a MySQL szerver vezet az alábbi sorokkal van tele folyamatosan:
2018-11-21T07:41:39.653890Z 123605 [Note] Aborted connection 123605 to db: '' user: '' host: '192.168.1.252' (Got timeout reading communication packets)
2018-11-21T07:42:01.564092Z 123894 [Note] Aborted connection 123894 to db: '' user: '' host: '192.168.1.252' (Got timeout reading communication packets)
2018-11-21T07:42:06.961086Z 123786 [Note] Aborted connection 123786 to db: '' user: '' host: '192.168.1.252' (Got timeout reading communication packets)
2018-11-21T07:42:17.027146Z 124046 [Note] Aborted connection 124046 to db: '' user: '' host: '192.168.1.252' (Got timeout reading communication packets)
2018-11-21T07:42:29.759601Z 122790 [Note] Aborted connection 122790 to db: '' user: '' host: '192.168.1.252' (Got timeout reading communication packets)
2018-11-21T07:43:15.211959Z 121478 [Note] Aborted connection 121478 to db: '' user: '' host: '192.168.1.252' (Got timeout reading communication packets)

Próbáltam már program kód szinten megoldani, mert sok helyen lehet arról olvasni, hogy a programba a lekérdezéseket kell kicsit másképp megfogalmazni, de ez mind mese habbal. Olyan nyaka tekert megoldásokat javasolnak, ami abszolút nem életszerű.

Nem tudom merre keressem a hibát. Másra már nem tudok gondolni, mint hogy a szerver beállításain kellene csiszolnom. Találkozott már valaki hasonlóval? Oldott már meg valaki hasonló problémát? Előre is köszönöm az építő jellegű hozzászólásokat.

MySQL szerver konfig beállításai:

[mysqld]
#
# * Basic Settings
#
character-set-server = utf8
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
max_connections = 100
skip-external-locking

connect_timeout = 10
interactive_timeout = 100
wait_timeout = 100

#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 0.0.0.0
#bind-address = 127.0.0.1

#
# * Fine Tuning
#
key_buffer_size = 128M
join_buffer_size = 16M
max_allowed_packet = 128M
table_open_cache = 128M
sort_buffer_size = 1024K
net_buffer_length = 64K
read_buffer_size = 1024K
read_rnd_buffer_size = 1024K
myisam_sort_buffer_size = 8M
thread_stack = 192K
thread_cache_size = 8
tmp_table_size = 24M
max_heap_table_size = 24M

sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options = BACKUP
thread_cache_size = 16K
#table_cache = 64

#
# * Query Cache Configuration
#
query_cache_type = 1
query_cache_size = 32M
query_cache_limit = 16M

#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1

#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log

#
# Here you can see queries with especially long duration
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysqld_slow_queries.log
long_query_time = 1
#log-queries-not-using-indexes

#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name

#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# the rest of the innodb config follows:
# don't eat too much memory, we're trying to be safe on 64Mb boxes
# you might want to bump this up a bit on boxes with more RAM
innodb_buffer_pool_size = 128M
# you may wish to change this size to be more suitable for your system
# the max is there to avoid run-away growth on your machine
innodb_data_file_path = ibdata1:10M:autoextend
# we keep this at around 25% of of innodb_buffer_pool_size
# sensible values range from 1MB to (1/innodb_log_files_in_group*innodb_buffer_pool_size)
innodb_log_file_size = 48M
# this is the default, increase it if you have very large transactions going on
innodb_log_buffer_size = 8M
# this is the default and won't hurt you
# you shouldn't need to tweak it
innodb_log_files_in_group=2
# see the innodb config docs, the other options are not always safe
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_deadlock_detect = 0
innodb_file_per_table

# Uncomment this to get FEDERATED engine support
#plugin-load=federated=ha_federated.so
loose-federated

#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

Egyedi névszerver megadása a systemd-resolver kikerülésével (Ubuntu 18.04)

Fórumok

Sziasztok!

Ubuntu 18.04-et használok (már), amiben benne van ez a csodás systemd-resolver. A gépen az LXC konténerek saját alhálózatot használnak és dnsmasq-kal kapnak névfeloldást a saját TLD-jük miatt (.test).

Először ezt bekötöttem a systemd-resolver alá, ez alapján:
https://blog.simos.info/how-to-use-lxd-container-hostnames-on-the-host-…

Viszont az a gondom, hogy a systemd-resolver összeakad a dnsmasq-kal, indokolatlanul magas CPU terhelést okozva:
https://unix.stackexchange.com/questions/417645/dnsmasq-systemd-causing…
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099

Egyelőre nem szeretném ezt a systemd-resolver csodát kidobni, a dnsmasq szépen elműködik az lxcbr0-ra kötve. Viszont valahogy fel kellene vennem a rendszer által használt névszerverek közé.
Az /etc/resolv.conf alapból nem jó, mert az egy link az /run/systemd/resolve/stub-resolv.conf fájlra, ami meg systemd-sen csak annyit mond, hogy „nameserver 127.0.0.53”
Ha kidobom a linket és újra létrehozom az /etc/resolv.conf-ot, akkor a network-manager kezdi el piszkálni. Viszont a network managernek bármilyen névszerver címet adok meg asz eszköznél, az figyelmen kívül hagyja. Azt gyanítom, hogy átpasszolja a systemd-nek, mert ugyanúgy csak annyit vesz fel, hogy „nameserver 127.0.0.53”
Nekimentem a netplannal is, ami elég jó cuccnak tűnik, csak ugye az meg a network-managert használja, ha van.

Kérdésem: hogyan tudnék permanensen másik névszervert megadni a rendszerben a systemd-resolver kikerülésével?

Az iptables physdev match tényleg csak a bridge-elt csomagokat latja, a route-oltakat pedig nem?

Fórumok

Sziasztok!

Adott egy Linux gép a következő három hálókártyával: eth0, eth1 és eth2. Az utóbbi kettő a br1 nevű virtuális switch interfésze:


root@rt:~# brctl show
bridge name      bridge id               STP enabled     interfaces
br1              8000.90e2ba7a1ae6        no              eth1
                                                          eth2

Létrehozok egy iptables szabályt, amivel MINDEN olyan új csomagot el szeretnék kapni, ami az eth2 interfészen megy ki:

iptables -t filter -A FORWARD -m physdev --physdev-out eth2 -m state --state NEW -j TABLE_eth2

Igen ám, de azt tapasztalom, hogy ez a physdev alapú szabály csak azokat az eth2-n kimenő csomagokat látja, amelyek az eth1-en jöttek be (azaz bridge-eltek), de az eth0-n bejövőket (azaz route-oltakat) nem. Tényleg ez a helyzet, vagy én rontottam el valamit? Rá lehet valahogy a physdev match-et, hogy route-olt csomagokat is lásson? Ha a csomag egy MÁSIK virtuális bridge egyik interfészén jönne be, azaz két bridge között route-olva lenne, akkor sem látná a physdev match?

Előre is köszönöm a válaszokat.

SAMBA 4 + ZFS snapshot

Fórumok

Sziasztok

Samba-val szeretnék egyfajta shadow copy-t megvalósítani.
Ehhez elvileg snapshotokat kell ütemezve létrehoznom, amit a kliensek adott mappára vonatkozva látnak és vissza tudják belőle állítani a korábbi verziókat.

Akárhogy csavarom a snapshot neveket, samba configot, a kliens nem lát előző verziót. Windowsos fájlszerverrel is teszteltem. A kliensek ott jól működnek.

próbálkozásaim
smb.conf


[sambashare]
    comment = ZFS dataset with Previous Versions enabled
    path = /data/smb
    read only = no
    browsable = yes
    vfs objects = shadow_copy2
#    vfs objects = shadow_copy_zfs
    shadow: snapdir = .zfs/snapshot
    shadow: sort = desc
    shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M
#    shadow: format = %Y-%m-%d-%H%M
    shadow: localtime = yes

[global]
    vfs objects = shadow_copy2
    shadow: snapdir = .zfs/snapshot
    shadow: sort = desc
#    shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M
    shadow:localtime = no

zfs snapshotok:


data/smb@GMT-2018.09.11-12.40.08                    9K      -  19.5K  -
data/smb@zfs-auto-snap_weekly-2018-09-16-0447       9K      -  19.5K  -
data/smb@zfs-auto-snap_weekly-2018-09-23-0447        0      -  1.94G  -
data/smb@zfs-auto-snap_weekly-2018-09-30-0447        0      -  1.94G  -

Hogy kellene ezt összehangolni?

Debian-9.5.0 EXT4 file rendszerű partíciók nem a valós szabad területet mutatják

Fórumok

Sziasztok!

Szervert cserélünk az egyik telephelyen, mert az aktuális 10 éves szerver már erősen kopott állapotban volt.

Az Új DELL T130 szerverben egy Perc H330-as HW Raid kártya van, 2x2TB 7.2R RPM NSAS l2Gbps 3.5" méretű HDD-vel.

Debian 9.5.0 került telepítésre , EXT-4 file rendszerrel , külön partíciókra helyezve a fontosabb adatokat.

Kernel: Linux hotel-srv 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux

Telepítés után azt vettem észre, hogy a df -h kimenete nem valós adatokat ad a foglalt terület alapján a szabad területre a nagyobb partíciók esetében ( > 10 Gb )

Valós adatok még nem lettek átmozgatva a régi szerverről, az újra, mert egyelőre tesztelés alatt van az új szerver.

Fájlrendszer Méret Fogl. Szab. Fo.% Csatol. pont
udev 7,8G 0 7,8G 0% /dev
tmpfs 1,6G 8,8M 1,6G 1% /run
/dev/sda1 59G 2,4G 54G 5% /
tmpfs 7,8G 0 7,8G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 7,8G 0 7,8G 0% /sys/fs/cgroup
/dev/sda7 358G 7,9G 332G 3% /virtualbox
/dev/sda6 469G 73M 445G 1% /flexys
/dev/sda8 917G 77M 870G 1% /hotel-share
tmpfs 1,6G 0 1,6G 0% /run/user/1000

Ez hw problémára utalhat, vagy csak a particionáláskor ronthattam el valamit?
Később lehet ebből komolyabb probléma, vagy figyelmen kívül hagyhatom, mert ez csak kezdeti helyfoglaláskor számol ilyen módon?

A választ és a segítséget előre is köszönöm!

[SOLVED]dhcpcd(?) problem

Fórumok

szisztok,
szituáció: új céges notebook. Munkahelyen dhcpből kapok lan-on ip-t.
Hazaviszem a notebookot és ha otthon is felcsatlakozok a hálózatra,
nem felejti el a benti címet, hanem mellé kap egy másikat, így két ip címem lesz.
De wifin ugyanez a probléma... :O
A notebookon van pi-hole, meg privoxy is, és ezt a régi notebookon nem csinálta.
Egyébként Linux Mint 18.3, tűzfal, patchek, stb rendben vannak....(4.15.0-38 kernel)
Mi miatt nem reseteli az interfészt a dhcp?
Van ötlete valakinek?
köszi,
fgy

drbd+mdadm+failed disk

Fórumok

Sziasztok!

Adott 2 node-ból álló drbd. Mindkét node-on raid1 mdadm van alatta.
Ha az egyik node-on kiesik egy diszk, az mdadm 60(?) másopercig blokkolja a raidet, míg próbálja életrekelteni a hibás diszket, majd kilöki a raidből. Ezen idő alatt az drbd széthullik, split-brain állapot lesz. Ez már 2x előfordult.
Tippünk szerint valamelyik timeout értéket kell hangolni a drbd configban, de nem találtuk meg egyértelműen google alapján sem.
Hamarosan tesztvason összeállítjuk kikisérletezni.
Sokat segítene, hogy mely paraméterek(et) kell maszírozni.

Köszönöm!