106
Server / Re:UFW pravidlo - zakaz komunikacie von (block outgoing traffic)
« kdy: 12. 10. 2017, 13:05:26 »
nikto okrem mna tam nema ucet a ja som tam nic take nenastavoval.
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
107
Server / Re:UFW pravidlo - zakaz komunikacie von (block outgoing traffic)
« kdy: 12. 10. 2017, 08:57:36 »108
Server / UFW pravidlo - zakaz komunikacie von (block outgoing traffic)
« kdy: 11. 10. 2017, 14:09:03 »
Ahoj,
prosim o radu.
Mam na serveri (ubuntu) v hostingu nastavene nasledujuce pravidlo v UFW:
ja zijem v tom, ze to nie je mozne, pretoze to pravidlo (podla mna) funguje, vid napr:
otazka znie:
mam to nastavene blbo? ak ano, ako to ma byt spravne?
ciel je zakazat akukolvek komunikaciu z mojho servera na celu mnozinu IP adries X.Y.Z.0 - X.Y.Z.255
dakujem
prosim o radu.
Mam na serveri (ubuntu) v hostingu nastavene nasledujuce pravidlo v UFW:
Kód: [Vybrat]
[ 3] X.Y.Z.0/24 DENY OUT Anywhere (out)
avsak hosting ma z casu na cas upozornuje na to, ze z mojho servera bola zistena aktivita na IP adresu X.Y.Z.W a port 80ja zijem v tom, ze to nie je mozne, pretoze to pravidlo (podla mna) funguje, vid napr:
Kód: [Vybrat]
$ ping X.Y.Z.W
PING X.Y.Z.W (X.Y.Z.W) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
^C
--- X.Y.Z.W ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
otazka znie:
mam to nastavene blbo? ak ano, ako to ma byt spravne?
ciel je zakazat akukolvek komunikaciu z mojho servera na celu mnozinu IP adries X.Y.Z.0 - X.Y.Z.255
dakujem
109
Server / Re:Hlavička „Received“ v e-mailové komunikaci
« kdy: 06. 02. 2017, 10:11:06 »Čili za předpokladu, že IP adresa virtual.domain.com má správně nastavený i reverzní záznam, stačí přinutit mailserver, aby odesílal z této adresy, což se dá v postfixu zařídit volbou (netestováno)Kód: [Vybrat]smtp_bind_address = VIRTUAL.IP.ADD.RESS
jo, to je presne ono, dakujem uz to funguje.
len pre ujasnenie:
toto zabezpeci, ze na mojom serveri bude postfix nacuvat len na tychto ip adresach
Kód: [Vybrat]
inet_interfaces = VIRTUAL.IP.ADD.RESS, 127.0.0.1
a toto zabezpeci, ze postfix z mojho servera pri komunikacii s inym serverom bude komunikovat vyhradne z VIRTUAL.IP.ADD.RESS ip adresy
Kód: [Vybrat]
smtp_bind_address = VIRTUAL.IP.ADD.RESS
rozumiem tomu spravne?
P.S. teraz som si v dokumentacii vsimol:
"Note 1: when inet_interfaces specifies no more than one IPv4 address, and that address is a non-loopback address, it is automatically used as the smtp_bind_address."
takze preto to zrejme vo vascine pripadov (ked postovy server bezi vyhradne ako dedicated) funguje out-of-the-box
110
Server / Hlavička „Received“ v e-mailové komunikaci
« kdy: 05. 02. 2017, 21:50:10 »
Ahojte,
prosim vas, ako prinutim postfix, aby sa v zatvorke v prvom riadku namiesto realneho nazvu a realnej IP adresy zobrazovalo "virtual.domain.com" a IP adresa tejto virtualnej sietovky?
je to ubuntu 16.04.1, postfix, REAL.IP.ADDRESS je realna verejna IP adresa servera s nazvom "realname.domain.com" a
virtual.domain.com je A zaznam domeny "domain.com" ktory ukazuje na virtualnu IP adresu na tomto realnom serveri.
MX zaznam pre celu domenu "domain.com" je nastaveny na virtual.domain.com, postix resp. port 25 bezi len na virtualnej IP adrese a na localhoste.
kod dole je kompletna "obfuskovana" hlavicka emailovej komunikacie s konzoloveho "mail" prikazu na zaslanie emailu na ucet na sezname.
ak poslem mail z roundcube (na adrese webmail.domain.com), ktory bezi na tomto serveri, tak je 1. hlavicka Received rovnaka a 2. je nahradena touto:
ak sa pozriem na hlavicky emailov, ktore mam v schranke, tak vacsinou to je tak, ako pozadujem, napr.
prosim vas, ako prinutim postfix, aby sa v zatvorke v prvom riadku namiesto realneho nazvu a realnej IP adresy zobrazovalo "virtual.domain.com" a IP adresa tejto virtualnej sietovky?
je to ubuntu 16.04.1, postfix, REAL.IP.ADDRESS je realna verejna IP adresa servera s nazvom "realname.domain.com" a
virtual.domain.com je A zaznam domeny "domain.com" ktory ukazuje na virtualnu IP adresu na tomto realnom serveri.
MX zaznam pre celu domenu "domain.com" je nastaveny na virtual.domain.com, postix resp. port 25 bezi len na virtualnej IP adrese a na localhoste.
kod dole je kompletna "obfuskovana" hlavicka emailovej komunikacie s konzoloveho "mail" prikazu na zaslanie emailu na ucet na sezname.
Kód: [Vybrat]
Received: from virtual.domain.com (realname.domain.com [REAL.IP.ADDRESS])
by email-smtpd-v6.ng.seznam.cz (Seznam SMTPD 1.3.56) with ESMTP;
Sun, 05 Feb 2017 21:19:43 +0100 (CET)
Received: by virtual.domain.com (Postfix, from userid 1000)
id 123456789012; Sun, 5 Feb 2017 21:19:42 +0100 (CET)
Subject: test
To: <testuser@seznam.cz>
X-Mailer: mail (GNU Mailutils 2.99.99)
Message-Id: <20170205201942.123456789012@virtual.domain.com>
Date: Sun, 5 Feb 2017 21:19:42 +0100 (CET)
From: testuser@realname.domain.com (testuser)
ak poslem mail z roundcube (na adrese webmail.domain.com), ktory bezi na tomto serveri, tak je 1. hlavicka Received rovnaka a 2. je nahradena touto:
Kód: [Vybrat]
Received: from webmail.domain.com (localhost [127.0.0.1])
by virtual.domain.com (Postfix) with ESMTP id 123456789090
for <testuser@seznam.cz>; Sun, 5 Feb 2017 21:09:32 +0100 (CET)
ak sa pozriem na hlavicky emailov, ktore mam v schranke, tak vacsinou to je tak, ako pozadujem, napr.
Kód: [Vybrat]
Received: from mailer.hptronic.cz (mailer.hptronic.cz [82.99.162.133])
by email-smtpd-v9.ko.seznam.cz (Seznam SMTPD 1.3.56) with ESMTP;
111
Software / Re:AGPL licencia pre backend utility?
« kdy: 16. 01. 2017, 13:32:46 »V případě iTextu ještě můžete použít starší verzi, která byla pod jinou licencí. Pro vložení elektronického podpisu stačí.
ano, o tej moznosti viem, v minulosti som iText 2.X.X pouzival, ale kedze nemam problem s AGPL, tak ako sme si pisali, zostanem pri aktualnej verzii
112
Software / Re:AGPL licencia pre backend utility?
« kdy: 16. 01. 2017, 11:21:10 »AGPL říká, že jakmile používáte odvozené dílo, musíte zveřejnit zdrojáky.
aha, toto mi nejak uniklo pozornosti, tym sa to prakticky vyriesilo, a z povodnych mojich 3 moznosti, mam teda len 1. a 2. a teda akonahle niekde v tom mojom stacku pouzivam iText a nechcem porusit AGPL musim tu utilitu zverejnit.
dakujem za vysvetlenie.
113
Software / Re:AGPL licencia pre backend utility?
« kdy: 16. 01. 2017, 09:47:23 »
v tomto konkretnom pripade k modifikacii iTextu nedochadza, ide len o pouzitie v zmysle "as-is". Co ale v hypotetickom pripade, ze by som iText modifikoval? Zrejme sa zial dostavame opat na zaciatok.
Este som trochu hladal a nasiel som priamo na roote tento clanok:
https://www.root.cz/clanky/affero-gplv3-vydejte-zdrojove-kody-sitovych-aplikaci/
a dokonca niekoho v diskusii prave napadol moj pripad.
https://www.root.cz/clanky/affero-gplv3-vydejte-zdrojove-kody-sitovych-aplikaci/nazory/144584/
Este som trochu hladal a nasiel som priamo na roote tento clanok:
https://www.root.cz/clanky/affero-gplv3-vydejte-zdrojove-kody-sitovych-aplikaci/
a dokonca niekoho v diskusii prave napadol moj pripad.
https://www.root.cz/clanky/affero-gplv3-vydejte-zdrojove-kody-sitovych-aplikaci/nazory/144584/
114
Software / AGPL licencia pre backend utility?
« kdy: 16. 01. 2017, 08:12:27 »
Zdravim,
aktualne riesim ako sa postavit k danej situacii a prosim tunajsich diskuterov o nazor - samozrejme, nebudem ho brat ako nazor pravnika, ide mi len o nazor, ako to vidi niekto iny od fachu.
Tu je situacia:
Uzivatel si v mojom eshope vlozi do kosika software. Platba prebehne cez PayPal a nasledne PayPal notifikuje moj web o uspesnej platbe. Web vola skriptom uctovny software, z neho vypadne PDF faktura, nasledne iny script predhodi tuto PDF fakturu java utilite, ktora pomocou iText-u vlozi do PDF elektronicky podpis. nasledne je faktura odoslana zakaznikovi.
iText je licencovany pod AGPL a ak spravne chapem AGPL, tak sa jedna zjednodusene o GPL pre aplikacie s ktorymi "koncovy uzivatel komunikuje po sieti". Otazka znie: Komunikuje tento moj zakaznik s mojou java utilitou po sieti? Resp. popisuje/(vztahuje sa na)AGPL tento use-case?
iText je dual licencovany, t.j. kupim si ho a nemusim to riesit, alebo je pre mna zavazna AGPL licencia. Ak je zavazna, tak mam povinnost splnit, co pozaduje licencia, tj. zverejnit java kody na webe, atd... - co nie je problem, ide o utilitku na jednotky riadkov, mna skor zaujima tento problem vseobecne.
napr. ak by bol pod AGPL licencovany nejaky PHP framework, v ktorom je napisany moj web, tak nie je o com sa bavit, musim zverejnit cely kod webu, alebo cely web by bol napisany v java a iText by bolo len jedno z mnohych jar-iek prilinkovanych k mojmu war-u/ear-u.
ale ako sa k tomu postavit v mojom pripade?
Aby som to este zjednodusil, podla mna mam 3 moznosti:
1) kupim si iText - a nemusim nic zverejnovat
2) plati pre mna AGPL licencia - nic neplatim, ale musim zverejnit kod
3) tento pripad nespada pod AGPL - a nemusim teda nic ale ako "favor" mozem sa k tomu postavit ako v bode 2
dakujem za vsetky podnety.
aktualne riesim ako sa postavit k danej situacii a prosim tunajsich diskuterov o nazor - samozrejme, nebudem ho brat ako nazor pravnika, ide mi len o nazor, ako to vidi niekto iny od fachu.
Tu je situacia:
Uzivatel si v mojom eshope vlozi do kosika software. Platba prebehne cez PayPal a nasledne PayPal notifikuje moj web o uspesnej platbe. Web vola skriptom uctovny software, z neho vypadne PDF faktura, nasledne iny script predhodi tuto PDF fakturu java utilite, ktora pomocou iText-u vlozi do PDF elektronicky podpis. nasledne je faktura odoslana zakaznikovi.
iText je licencovany pod AGPL a ak spravne chapem AGPL, tak sa jedna zjednodusene o GPL pre aplikacie s ktorymi "koncovy uzivatel komunikuje po sieti". Otazka znie: Komunikuje tento moj zakaznik s mojou java utilitou po sieti? Resp. popisuje/(vztahuje sa na)AGPL tento use-case?
iText je dual licencovany, t.j. kupim si ho a nemusim to riesit, alebo je pre mna zavazna AGPL licencia. Ak je zavazna, tak mam povinnost splnit, co pozaduje licencia, tj. zverejnit java kody na webe, atd... - co nie je problem, ide o utilitku na jednotky riadkov, mna skor zaujima tento problem vseobecne.
napr. ak by bol pod AGPL licencovany nejaky PHP framework, v ktorom je napisany moj web, tak nie je o com sa bavit, musim zverejnit cely kod webu, alebo cely web by bol napisany v java a iText by bolo len jedno z mnohych jar-iek prilinkovanych k mojmu war-u/ear-u.
ale ako sa k tomu postavit v mojom pripade?
Aby som to este zjednodusil, podla mna mam 3 moznosti:
1) kupim si iText - a nemusim nic zverejnovat
2) plati pre mna AGPL licencia - nic neplatim, ale musim zverejnit kod
3) tento pripad nespada pod AGPL - a nemusim teda nic ale ako "favor" mozem sa k tomu postavit ako v bode 2
dakujem za vsetky podnety.
115
O serveru Root.cz / Re:Root RSS export - problem s certifikatom
« kdy: 10. 10. 2016, 12:30:21 »
jo , to by mohlo byt ono, ja bezim na jave 6.
dikes
dikes
116
O serveru Root.cz / Root RSS export - Java nezná certifikát
« kdy: 10. 10. 2016, 12:07:34 »
zdravim,
pouzivam vlastnu RSS citcku napisanu v Jave a pred par dnami som si vsimol, ze mi prestali fungovat RSS feedy na serveri root.cz - podla vsetkeho doslo k zmenu URL na ktorom exporty bezia, tak som URL zmenil, ale teraz mi to hlasi tuto chybu. Bolo by mozne na serveru root.cz pouzivat korektne certifikaty aj pre RSS exporty?
dakujem
pouzivam vlastnu RSS citcku napisanu v Jave a pred par dnami som si vsimol, ze mi prestali fungovat RSS feedy na serveri root.cz - podla vsetkeho doslo k zmenu URL na ktorom exporty bezia, tak som URL zmenil, ale teraz mi to hlasi tuto chybu. Bolo by mozne na serveru root.cz pouzivat korektne certifikaty aj pre RSS exporty?
dakujem
Kód: [Vybrat]
Worker error: Problem with rss url. [https://www.root.cz/rss/clanky/], caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Worker error: Problem with rss url. [https://www.root.cz/rss/diskuse/], caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Worker error: Problem with rss url. [https://www.root.cz/rss/zpravicky/], caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
117
Nabízím zakázku / prepis cutycapt do qtwebengine
« kdy: 22. 09. 2015, 11:36:41 »
Ahojte, hladam niekoho kto je schopny a ochotny za financnu odmenu prepisat CutyCapt (http://cutycapt.sourceforge.net/) z QtWebkit do QtWebengine.
Ponuky prosim zasielajte na cutycapt@seznam.cz
dakujem
m
Ponuky prosim zasielajte na cutycapt@seznam.cz
dakujem
m
118
Bazar / Re:Prodám NB Lenovo T61 bez grafiky
« kdy: 23. 04. 2013, 07:17:48 »
a este som si spomenul na povodnu RAM:
pridavam k NB este jeden funkcny 2GB RAM modul - originalny, ktory som neskor nahradil novymi 2x4GB
pridavam k NB este jeden funkcny 2GB RAM modul - originalny, ktory som neskor nahradil novymi 2x4GB
119
Bazar / Re:Prodám NB Lenovo T61 bez grafiky
« kdy: 22. 04. 2013, 19:50:07 »ahojte, ja mam napredaj toto:
NB Lenovo T61,
Intel Core 2 Duo T9300,
8GB RAM,
matny display 15,4", 680 x 1050,
bez HDD,
NVIDIA Quadro NVS 140M, DVD, 2ks baterie.
Pokazena graficka karta, ostatne komponenty su 100% funkcne. Cena dohodou
...este som zabudol: k notebooku mam aj sata hdd ultrabay adapter pre externy disk
120
Bazar / Prodám NB Lenovo T61 bez grafiky
« kdy: 22. 04. 2013, 11:58:30 »
ahojte, ja mam napredaj toto:
NB Lenovo T61,
Intel Core 2 Duo T9300,
8GB RAM,
matny display 15,4", 680 x 1050,
bez HDD,
NVIDIA Quadro NVS 140M, DVD, 2ks baterie.
Pokazena graficka karta, ostatne komponenty su 100% funkcne. Cena dohodou
NB Lenovo T61,
Intel Core 2 Duo T9300,
8GB RAM,
matny display 15,4", 680 x 1050,
bez HDD,
NVIDIA Quadro NVS 140M, DVD, 2ks baterie.
Pokazena graficka karta, ostatne komponenty su 100% funkcne. Cena dohodou
