Ahoj,
mam trosku problem s Dovecot (a mozna i necim dalsim, nevim). Z nejakeho
duvodu si mysli, ze nemam IPv6 ve VPS.
Jan 12 12:14:35 wolfsden systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
Jan 12 12:14:35 wolfsden systemd[1]: [/lib/systemd/system/dovecot.socket:8] Failed to parse address value, ignoring: [::]:143
Jan 12 12:14:35 wolfsden systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
Jan 12 12:14:35 wolfsden systemd[1]: [/lib/systemd/system/dovecot.socket:10] Failed to parse address value, ignoring: [::]:993
Nicmene server ipv6 samozrejme ma
root@wolfsden:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/void
inet 127.0.0.2/32 scope host venet0
inet 77.93.223.198/32 brd 77.93.223.198 scope global venet0:0
inet6 2a01:430:17:1::ffff:96/128 scope global
valid_lft forever preferred_lft forever
3: gre0: <NOARP> mtu 1476 qdisc noop state DOWN
link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
Ping ven funguje
root@wolfsden:/# ping6 ipv6.google.com
PING ipv6.google.com(waw02s06-in-x0e.1e100.net) 56 data bytes
64 bytes from waw02s06-in-x0e.1e100.net: icmp_seq=1 ttl=54 time=21.0 ms
64 bytes from waw02s06-in-x0e.1e100.net: icmp_seq=2 ttl=54 time=20.8 ms
64 bytes from waw02s06-in-x0e.1e100.net: icmp_seq=3 ttl=54 time=21.8 ms
Pres jeden web jsem overil, ze funguje i ping6 smerem ke mne.
root@wolfsden:/# test -f /proc/net/if_inet6 && echo "Running kernel is IPv6 ready"
Running kernel is IPv6 ready
root@wolfsden:/# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
0
Proc si dovecot mysli, ze kernel nema IPv6?
Diky,
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Ahoj,
muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne
pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS
ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co
potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to
melo udelat)?
Dik :)
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Dneska uz ten rozdil neni az tak markantni, ale v dobe kdy sme zavadeli zfs
jako stabilni tak btrfs rozjebavalo data 2x denne :) jinak ja treba
soukrome pouzivam zfs protoze umi krom datasetu i zvol, ma pohodlnejsi
praci se snapshotama a dalsi drobnosti.
Kazdopadne posledni cca rok je btrfs skoro i pouzitelny, ikdyz ja mu osobne
porad neverim :)
Gh.
On Jan 10, 2017 19:08, "Wolf" <wolf(a)wolfsden.cz> wrote:
Ahoj,
muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne
pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS
ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co
potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to
melo udelat)?
Dik :)
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
snazim se nastavit openvpn server tak, abych pres nej mohl pristupovat
dal do inernetu, ale nedari se mi to.
Sel jsem podle tohoto navodu:
https://blog.sslmarket.cz/ssl/nastaveni-openvpn-na-serveru-s-debian-8-jessi…
a podari se mi pres vpn dostat na server, ale dal uz ne (ani nepingnu).
Predpokladam, ze je nejaky problem v nastaveni iptables, zkousel jsem i
|iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -j MASQUERADE|
i podle navodu z https://kb.vpsfree.cz/navody/server/openvpn
iptables -t nat -A POSTROUTING -o venet0 -j SNAT --to x.x.x.x
|Diky za jakekoliv nakopnuti nebo upravu vpsfree navodu. Pavel Švojgr ---
vypisy nastaveni ---- |
# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 10.8.0.0/24 anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# tail /var/log/syslog
Jan 6 16:35:09 svojgr ovpn-server[10656]: 188.122.208.66:37508 [swed]
Peer Connection Initiated with [AF_INET]188.122.208.66:37508
Jan 6 16:35:09 svojgr ovpn-server[10656]: swed/188.122.208.66:37508
MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Jan 6 16:35:09 svojgr ovpn-server[10656]: swed/188.122.208.66:37508
MULTI: Learn: 10.8.0.6 -> swed/188.122.208.66:37508
Jan 6 16:35:09 svojgr ovpn-server[10656]: swed/188.122.208.66:37508
MULTI: primary virtual IP for swed/188.122.208.66:37508: 10.8.0.6
Jan 6 16:35:11 svojgr ovpn-server[10656]: swed/188.122.208.66:37508
PUSH: Received control message: 'PUSH_REQUEST'
Jan 6 16:35:11 svojgr ovpn-server[10656]: swed/188.122.208.66:37508
send_push_reply(): safe_cap=940
Jan 6 16:35:11 svojgr ovpn-server[10656]: swed/188.122.208.66:37508
SENT CONTROL [swed]: 'PUSH_REPLY,redirect-gateway def1,route
10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6
10.8.0.5' (status=1)
# cat server.conf
mode server
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # privátní klíč serveru, nikam nepřenášet!
dh dh2048.pem
server 10.8.0.0 255.255.255.0
#push "redirect-gateway autolocal" #přesměrování všeho provozu do tunelu
push "redirect-gateway def1"
#push "dhcp-option DNS 217.31.204.130" #budete používat otevřené
resolvery CZ.NICu
#push "dhcp-option DNS 193.29.206.206"
#tls-server
#tls-auth ta.key 0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
user nobody
group users
status openvpn-status.log
verb 3
# cat /etc/sysctl.conf |grep ip_forward
net.ipv4.ip_forward=1
# cat openvpn-status.log
OpenVPN CLIENT LIST
Updated,Fri Jan 6 16:42:17 2017
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
swed,188.122.208.66:58268,75127,4993,Fri Jan 6 16:41:55 2017
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.6,swed,188.122.208.66:58268,Fri Jan 6 16:42:16 2017
GLOBAL STATS
Max bcast/mcast queue length,0
END
# iptables-save
# Generated by iptables-save v1.4.21 on Fri Jan 6 16:57:14 2017
*raw
:PREROUTING ACCEPT [198913:44347927]
:OUTPUT ACCEPT [177047:151548665]
COMMIT
# Completed on Fri Jan 6 16:57:14 2017
# Generated by iptables-save v1.4.21 on Fri Jan 6 16:57:14 2017
*nat
:PREROUTING ACCEPT [2998:172636]
:POSTROUTING ACCEPT [1398:83622]
:OUTPUT ACCEPT [1398:83622]
-A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
COMMIT
# Completed on Fri Jan 6 16:57:14 2017
# Generated by iptables-save v1.4.21 on Fri Jan 6 16:57:14 2017
*mangle
:PREROUTING ACCEPT [178768:43049496]
:INPUT ACCEPT [178768:43049496]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [177047:151548665]
:POSTROUTING ACCEPT [177047:151548665]
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,ACK,URG -j DROP
-A PREROUTING -s 224.0.0.0/3 -j DROP
-A PREROUTING -s 169.254.0.0/16 -j DROP
-A PREROUTING -s 172.16.0.0/12 -j DROP
-A PREROUTING -s 192.0.2.0/24 -j DROP
-A PREROUTING -s 192.168.0.0/16 -j DROP
-A PREROUTING -s 10.0.0.0/8 -j DROP
-A PREROUTING -s 0.0.0.0/8 -j DROP
-A PREROUTING -s 240.0.0.0/5 -j DROP
-A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP
-A PREROUTING -p icmp -j DROP
-A PREROUTING -f -j DROP
COMMIT
# Completed on Fri Jan 6 16:57:14 2017
# Generated by iptables-save v1.4.21 on Fri Jan 6 16:57:14 2017
*filter
:INPUT ACCEPT [8741:3756481]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7936:4515300]
COMMIT
# Completed on Fri Jan 6 16:57:14 2017
Ahojte,
letos jsme to nejak prokaucovali s clenskou schuzi, kterou jsme nestihli
udelat.
Pojdme ji proto udelat v lednu;
Ona clenska schuze ve vpsFree je v podstate organ, ktery by se ani
nemusel schazet, kdyz vsechno funguje - protoze jedine, co clenska
schuze resi, je volba lidi do organu sdruzeni, pokud se dostanou pod
minimalni stav.
Je to tedy spis vyrocni setkani a bilancni zhodnoceni dalsiho roku
fungovani.
Novy obcansky zakonik povazuje schuzi za usnasenischopnou, sejde-li se
nadpolovicni vetsina clenu; nesejde-li se, svolava se schuze nahradni (v
nasi uprave stanov za tyden od neuspesneho prvniho pokusu).
Tuhle tancovacku by bylo vhodne zrusit, protoze pri 1100+ clenech je
velmi nepravdepodobne, ze se nas sejde na jednom miste vic, jak 500.
Cili bych to videl tak, ze na schuzi v lednu pripravime ustne hruby
nastrel toho, jak by mohlo vypadat takove hlasovani elektronicky s tim,
ze bychom se sesli fyzicky rovnou na prvni pokus bez nutnosti druheho a
hlasovaci cast by probehla elektronicky (cili za rok budem u piva
vsichni koukat chvili do notebooku, kdyz bude o cem hlasovat ;)).
Na tuhle lednovou schuzi podle vseho nebude potreba hlasovat o nicem, a
tak budeme jenom bilancovat + mluvit o planech do budoucna. Ja bych to
tedy videl tak, pokud nikdo nejste proti, pojdme se sejit jednou a
nedelejme saradu s pred-terminem a o-tyden-opozdenou nahradni clenskou
schuzi.
Mate nekdo navrh na podnik (v Praze), kde by se clenska schuze mohla konati?
Kde jsme schuze delali do ted, uz se budto nevejdeme, nebo jsou velmi
negativni zkusenosti s obsluhou (posledni clenska schuze ukazala fakt
obrovskou ochotnost mistniho personalu).
Odhadem se nas sejde tak 50.
Diky predem za tipy.
/snajpa
(Pavel Snajdr)
Ahoj kluci,
před malou chvílí mě překvapil, že chodí z podpory a z listů přes
nešifrovaná spojení.
Řešení se mi zdá jednoduché - stačí i self signed certifikát nebo použít
wircard cert, který máte na vpsfree. Sám léta používám self signed a žádný
problém, aspoň mi gmail neřve, že mail nebyl zašifrován. Toto řešení
používám už dlouho - od doby, co začal gmail křičet.
Co vy na to kluci?
Petr Parolek
