Debian GNU/Linux

Hi!

Lészen két interface és minkettőhöz szeretnék két átjárót beállítani. Úgy tűnik sikerült is, de ha csatlakoznék akkor mégsem megy.

Internet---GW1[192.168.1.1]----[192.168.1.112]MASINA[10.0.0.112]----[10.0.0.5]GW2---Internet

#route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 10.0.0.5 255.255.255.0 UG 0 0 0 eth1
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

/etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.1.112
netmask 255.255.255.0
broadcast 192.168.1.255

auto eth1
iface eth1 inet static
address 10.0.0.112
netmask 255.255.255.0
broadcast 10.0.0.255

post-up route add default dev eth1
post-up route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.5 eth1
post-up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1 eth0

Így sajna kintről - forward-al - nem érem el a gépet, mert a routing csak nem akar menni. Valakinek ötlete?

Előre is köszönöm!

Sziasztok,
Kis segítségre lenne szükségem.
Az előzmények kevéssé érdekesek, a lényeg, hogy a squeeze-alapú levelezőszerverem évek óta megy hiba nélkül (postfix-dovecot), de egy csomagfrissítés során dependenciákba ütköztem, melynek során eltávolításra került többek között a postfix is.
A sources.list file-on nem változtattam, jelenleg az apt-get update/upgrade/dist-upgrade probléma nélkül lefut.
Viszont szeretném visszarakni a postfix-ot, de arra azt mondja, hogy

postfix : Depends: libsasl2-2 but it is not going to be installed

apt-get install libsasl2-2 -re azt mondja:

libsasl2-2 is already the newest version.

aptitude install postfixre ezt kapom:
The following packages have unmet dependencies:
libsasl2-2: Breaks: postfix (<= 2.8.3-1) but 2.7.1-1+squeeze1 is to be installed.

Tehát mintha nem megfelelő Postfix verziót akarna feltenni?

Kicsit meg vagyok lőve, hogy most akkor hogyan tovább...
Esetleg van valakinek tippje?

Előre is köszönöm!

üdv:
optimista

Üdv kedves HUP júzerek!

(a kérdés nem kifejezetten Debianos, de mivel Debianon vagyok...)

Debian 7 Wheezy-n vagyok és Windows 7-ről jövök. Mivel meghalt a GeForce 9800GTX-em és kénytelen vagyok a Radeon X1050-em használni, a játék többé nem téma (meg amúgy sem érdekel már), így semmi sem tartott vissza, hogy végre váltsak. Ki is próbáltam az OpenSUSE 12.3-at, de több gondom is volt vele, pl hogy sok csomag nincs rá. Aztán átjöttem Debian Wheezyre, mert az Ubuntu nem fekszik, ahogy a Mint sem, de az apt-t meg szeretem, ahogy a csomagválasztékot is.

Viszont a / -t leszeámítva minden merevlemezem NTFS formátumban van még. A nagy kérdés az, hogy megéri-e valamilyen *nix -os formátumra átalakítani őket? Teljesítményben / fragmentálódásban mennyi előnye lenne és milyen fájlrendszert ajánlotok?
Az alap 3.2 -es kernelt használom, ha ez számít.

(egyébként nagyon tetszik a debian, meglepően stabil)

Van egy Debian 6.0 alapu Xen hypervisorom, amivel azt hibajelenseget tapasztalom, hogy egy ido utan az SSH kapcsolat megall, majd par perc mulva tovabb megy, megy egy ideig, majd megint megall. A "mukodik" szakasz ideje olyan egy-masfel perc lehet max, az "all" szakasz viszont attol fugg, 2-5 perc is volt mar.

A fentit mind maga a hypervisor, mind pedig a virtualis gepek jatszak, szoval nem gondolok tuzfal szintu mokara.
Egyebkent a gepen - mivel nincs az internet fele kozvetlenul laba - semmilyen tuzfal nincs, attol a par iptables rule-tol eltekintve, amit a Xen maga intez.

A gepnek egy darab laba van csak, ami egy Cisco 2950 switchbe megy, amin nincs semmilyen vedelem konfiguralva (ez egy management switch, csak altalam menedzselt privat halos cimek vannak rajta, elerni internet felol nem lehet semmilyen modon).

Korabban ez a gep valtozatlan hardverkonfiguracioval MySQL szerverkent uzemelt, a mukodes soran ilyen jellegu hibat nem tapasztaltunk, illetve az SSH-val se volt gond soha. Ez a hiba azota van, amiota a gep ujra lett telepitve (egy debian 5.0 volt a MySQL szerver).

Igazabol azt se tudom, merre keresgeljek. A logokban elso ket korben semmi nincs (se a gepen, se a management switchben), probaltam a rx/tx checksum offloadingot tiltani, probaltam SSH keepalive-t konfiguralni, eddig semmi nem segitett.

Mas, hasonlo hardver/szoftver parositasu gepen a problemat nem tapasztalom.

Ha valaki csak google keresoszavakkal segitene, mar azzal is elorebb lennek.

Régóta nyűglődik a notebookom (DELL LATITUDE E6520) ezzel a problémával.
Ha kiadom az "init 6" parancsot, belefagy a restart műveletbe.
Egészen odáig jut hogy "restarting system" és ott megáll :D

Van valakinek ötlete hogy mi lehet a baj?

Előre elnézést kérek a nagyon pengéktől :)
Totálisan kezdő vagyok perlben.

A következő script működik:

#!/usr/bin/perl
use DBI;
my $dsn='DBI:Pg:dbname=zabbix_test;host=192.168.0.10';
my $username='user';
my $password='pass';
my $dbh = DBI->connect($dsn, $username, $password, {'RaiseError' => 1});
my $query='SELECT hosts.name FROM hosts_groups, hosts where hosts_groups.hostid=hosts.hostid and groupid=62 order by hosts.name';
my $sth = $dbh->prepare($query);
$sth->execute();
while(my $ref = $sth->fetchrow_hashref()) {
print "$ref->{'name'}\n";
}
$dbh->disconnect();

Mindössze annyi a probléma, hogy a stdout helyett egy fileba szeretném kiírni az adott select eredményét.

Tudom amatőr kérdés, de hogyan tudom a select eredményét egy fájlba írni?
Jól gondolom, hogy az "$sth->fetchrow_hashref()" annyit csinál hogy az sth változónak átad egy hash kódot, amit a "print "$ref->{'name'}\n"-nél old fel, és ír ki?

Előre is köszi a segítséget!

Hi!

Debian squeeze, KVM és a virtuális gépek LVM-en. Egy fagyást követően az újrainduláskor az egyik virtuális gép nem indult el. Ránézve a virt. consolra, azt mondja nincs disk!
Gondoltam mountolom az LVM-et:
losetup /dev/loop0 /dev/mapper//dev/mapper/lvm--data-www
kpartx -av /dev/loop0

Na itt már gyanús volt, mert a kpartx közölni szokta, hogy "add map loop0p1 ...." és mennyi az eltolás stb. A "drága" semmi hiba nélkül semmit nem tett, az "ls -alF /dev/mapper"-ben nem látszik a loop0p1, gondolom nem csinálta meg.

Valakinek ötlete, hogy mi mehetett gajra az LVM-en?
Rá lehet venni esetleg valami "önellenőrzésre"?

#lvdisplay
--- Logical volume ---
LV Name /dev/lvm-data/www
VG Name lvm-data
LV UUID cm26er-tZHC-lsH2-GacK-p1Dy-TxDc-TL1eiM
LV Write Access read/write
LV Status available
# open 0
LV Size 50,00 GiB
Current LE 12800
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2


#lvscan
ACTIVE '/dev/lvm-data/www' [50,00 GiB] inherit
ACTIVE '/dev/lvm-data/www-swap' [2,00 GiB] inherit

A többi virtuális gép természetesen megy.
Bármilyen ötletet szívesen fogadok.

Sziasztok!

Segítséget szeretnék kérni a következő problémával: a postfix authentikáció nem működik kliens levelező programokkal, a következő hibaüzenet jön vissza :
5.7.1 relay access denied

A mail logban a következő hiba van:

Jul 2 18:58:47 (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) postfix/smtpd[6842]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
Jul 2 18:58:47 (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) postfix/smtpd[6842]: warning: SASL authentication failure: Password verification failed
Jul 2 18:58:47 (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) postfix/smtpd[6842]: warning: 5403AE5E.catv.pool.telekom.hu[84.3.174.94]: SASL PLAIN authentication failed: generic failure
Jul 2 18:58:47 (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) postfix/smtpd[6842]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
Jul 2 18:58:47 (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) (6:58:47 PM 12h) postfix/smtpd[6842]: warning: 5403AE5E.catv.pool.telekom.hu[84.3.174.94]: SASL LOGIN authentication failed: generic failure

Úgy néz ki az authdaemon is fut:
/var/log# ps -ef | grep auth
root 610 1 0 Jul02 ? 00:00:00 (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) /usr/sbin/courierlogger -pid=/var/run/courier/authdaemon/pid -start /usr/lib/courier/courier-authlib/authdaemond
root 614 610 0 Jul02 ? 00:00:00 (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) /usr/lib/courier/courier-authlib/authdaemond
root 768 614 0 Jul02 ? 00:00:00 (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) /usr/lib/courier/courier-authlib/authdaemond
root 769 614 0 Jul02 ? 00:00:00 (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) /usr/lib/courier/courier-authlib/authdaemond
root 770 614 0 Jul02 ? 00:00:00 (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) /usr/lib/courier/courier-authlib/authdaemond
root 771 614 0 Jul02 ? 00:00:00 (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) /usr/lib/courier/courier-authlib/authdaemond
root 772 614 0 Jul02 ? 00:00:00 (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) (12:00:00 AM 12h) /usr/lib/courier/courier-authlib/authdaemond

Webmailen keresztül lehet emaileket küldeni a szerverről.

A main cf tartalma:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = /usr/share/doc/postfix

# TLS parameters
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = mail.xxx.hu
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
#myorigin = /etc/mailname
mydestination = localhost, localhost.localdomain
relayhost =
smtpd_delay_reject = no
mynetworks = 127.0.0.0/8 xx.xxx.xxx.xx[::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination
#smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticate, reject_unauth_destination
smtpd_tls_auth_only = no
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
virtual_alias_domains =
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, proxy:mysql:/etc/postfix/mysql-virtual_email2email.cf, hash:/var/lib/mailman/data/virtual-mailman
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
smtpd_tls_security_level = may
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
relay_domains = mysql:/etc/postfix/mysql-virtual_relaydomains.cf
relay_recipient_maps = mysql:/etc/postfix/mysql-virtual_relayrecipientmaps.cf
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf
smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-virtual_client.cf
smtpd_client_message_rate_limit = 100
maildrop_destination_concurrency_limit = 1
maildrop_destination_recipient_limit = 1
virtual_transport = maildrop
header_checks = regexp:/etc/postfix/header_checks
mime_header_checks = regexp:/etc/postfix/mime_header_checks
nested_header_checks = regexp:/etc/postfix/nested_header_checks
body_checks = regexp:/etc/postfix/body_checks
content_filter = amavis:[127.0.0.1]:10024
owner_request_special = no
receive_override_options = no_address_mappings
message_size_limit = 0
html_directory = /usr/share/doc/postfix/html

smtpd.conf:


pwcheck_method: saslauthd
mech_list: plain login
allow_plaintext: true
auxprop_plugin: mysql
sql_hostnames: 127.0.0.1
sql_user: ispconfig
sql_passwd: xxxx
sql_database: xxxx
sql_select: select password from mail_user where login = '%u'


Mysql fut, adattáblák jók. Sajnos kifogytam az ötletekből, előre is köszi a segítséget!

Van egy régebbi Debian szerver (5.0) és egy internet kapcsolat, a belső hálón lóg jó néhány gép, illetve még 2 Debian szerver egyéb feladatokkal.
Körülbelül 1 hete, ha a belső hálózat bármelyik gépe pl. Windows frissítést, vagy akár az egyik belső Debian szerver tölt le bármit (tesztelésre debian iso-kat próbáltam
különböző magyar és külföldi szerverekről letölteni). A letöltés elmegy 40-80 MB-ig aránylag jó sebességgel majd egyszer csak elkezd csökkenni és megáll.

10% [=================> ]72.376.454 --.-K/s kész: 56m 47s

Ha a netes szerverre töltöm ugyanezt, akkor az megy rendesen.

2013-06-27 11:03:00 (1,12 MB/s) - ,,debian-7.1.0-i386-CD-1.iso" mentve [679477248/679477248]

Próbáltam a belső szerver és a netes szerver közt letölteni az is ment szépen

2013-06-27 10:37:30 (10,3 MB/s) -- „debian-7.1.0-i386-CD-1.iso” mentve [679477248]

A hálókártyákon nem látok se error-t , se collision-t. A belső lan kártya már cserélve lett, nem változott semmi, ugyanúgy megáll a letöltés.

Azóta már szinte minden újra lett indítva (szerver, kliens, switch stb), de ugyanaz a helyzet.

Az volna a kérdésem, hogy van-e valakinek tapasztalata postgresql cluster telepítésben, üzemeltetésben?

Azon gondolkodom, hogy jó volna a zabbix szerverem adatbázisán valamilyen fajta terheléselosztást megvalósítani.
Egyrészt tanulási célból, másrészt némileg hibatűrőbb és gyorsabb működés érdekében.
Teljesen kezdő vagyok a témában, de azért megpróbáltam utánajárni hogy milyen lehetőségek vannak.

Valaki írta hogy a postgresql 9.1-nek már van beépített cluster lehetősége.
A kérdés az hogy milyen?
Standby-t és hideg tartalékot nem szeretnék, mert semmit sem gyorsítana a jelenlegi rendszeren.

Nekem ha jól értem, akkor egy multi-master replikációra volna szükségem, ami ugye lehet szinkron vagy aszinkron.
A szinkronnál azt olvastam hogy a két szerver művelet esetén megvárja,
amíg mindkét adatbázison végrehajtásra kerül az aktuális változtatás, és csak utána lép tovább.

Azt is olvastam erről a módszerről, hogy lassabb írást eredményez mint ha egyetlen master szerverem lenne önmagában.
Ez így elsőre már nem jól indul, ezért kezdtem kacsingatni az aszinkron megoldás felé.
Valahol azt láttam hogy ez a postgresql alapértelmezett üzemmódja.
Viszont azt is láttam, hogy egy másik perl fejlesztéssel kiegészítve használják amit "Bucardo" nak hívnak.
Tehát a postgresql 9.1 alapból nem tudja a multi-master aszinkron replikációt, csak ezzel a fejlesztéssel kiegészítve?

Tehát az aszinkron módnál nem várja meg egymást a két szerver.
Gondolom ebben az esetben a még át nem szinkronizált változások elveszhetnének egy esetleges winchesterhiba esetén.

Ami még nem tiszta, hogy a master-slave szerverek esetén van-e bármilyen terhelésmegosztás?
A slave szerver csak a háttérben várakozik, és csak a master kiesése esetén lép az első helyre,
vagy adott esetben bizonyos terheltségi szint fölött a slave szerverre átirányítható a forgalom egy része?

Egyébként mennyire jár sok hibával és napi szintű fejvakargatással egy multimaster vagy egy master-slave adatbázis üzemeltetése?
Régóta mozgatja a terheléselosztás a fantáziám, de azt még nem tudom, hogy érdemes-e rá időt fordítanom.

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