From iulian.roman at gmail.com Wed Apr 7 21:40:30 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Wed, 7 Apr 2021 20:40:30 +0200 Subject: [rlug] http_proxy vs https_proxy Message-ID: <5EED75A3-C480-4794-BB00-2CDA4F606EA8@gmail.com> Poate cineva sa explice cat mai clar cand se foloseste una din variabile si cand cealalta si mai ales care este diferenta in modul de conectare la proxy server ? Este nevoie de configurare speciala la nivel de proxy pentru asta ? Am vazut ca in multe exemple http_proxy si https_proxy sunt setate fix la fel. In alte exemple http_proxy foloseste http si https_proxy foloseste https , deci se pare ca e destula confuzie. Am avut un lung debate pe tema asta si as fi foarte curios sa lamuresc problema . Orice link sau documentatie relevanta sunt binevenite (am citit cred majoritatea topicurilor de pe stackoverflow si am gasit numai jumatati de raspunsuri). As dori sa mentionez ca nu TLS proxy intercept ma intereseaza. From m at mokalife.ro Wed Apr 7 23:19:25 2021 From: m at mokalife.ro (Mihai) Date: Wed, 7 Apr 2021 23:19:25 +0300 Subject: [rlug] Problema routing In-Reply-To: <751b3be9-ba39-f9e5-8cfe-3f3aca1a7948@prolinux.ro> References: <26effbef-af3e-3d50-06b3-c0549433916a@prolinux.ro> <3f0910e6-a9cc-d9c4-8b7c-21c2d0e1f5fb@prolinux.ro> <0a496116-912f-9e37-ed5c-5ff7d0f2f508@nobugconsulting.ro> <751b3be9-ba39-f9e5-8cfe-3f3aca1a7948@prolinux.ro> Message-ID: Salut, Am ajuns la vrf-uri, imi functioneaza doar ca in momentul cand vreau sa fac un inter-vrf routing packetele ce se duc prin alt vrf nu-mi raspund, daca ma uit prin tcpdump pare in regula. Nu stiu daca inter-vrf routing functioneaza cand packetele sunt generate local. Ceva idei? Ping from green to 172.29.62.100 -> OK ping 172.29.62.100 -w 1 -O -D -I green ping: Warning: source address might be selected on device other than green. PING 172.29.62.100 (172.29.62.100) from 10.104.255.30 green: 56(84) bytes of data. [1617780221.851663] 64 bytes from 172.29.62.100: icmp_seq=1 ttl=63 time=1.25 ms --- 172.29.62.100 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.254/1.254/1.254/0.000 ms Tcpdump: tcpdump -ttni green tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on green, link-type EN10MB (Ethernet), capture size 262144 bytes 1617780221.849920 IP 10.104.255.30 > 172.29.62.100: ICMP echo request, id 936, seq 1, length 64 1617780221.851170 IP 172.29.62.100 > 10.104.255.30: ICMP echo reply, id 936, seq 1, length 64 ip ro ls vrf green 10.104.255.28/30 dev eth0.10 proto kernel scope link src 10.104.255.30 172.29.62.100 via 10.104.255.29 dev eth0.10 ---------- ip ro ls vrf red 10.104.255.50/30 dev eth0.10 proto kernel scope link src 10.104.255.50 default dev green Ping from red to 172.29.62.100 -> Failed ping 172.29.62.100 -w 1 -O -D -I red ping: Warning: source address might be selected on device other than red. PING 172.29.62.100 (172.29.62.100) from 10.104.255.30 red: 56(84) bytes of data. --- 172.29.62.100 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms tcpdump -ttni green tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on green, link-type EN10MB (Ethernet), capture size 262144 bytes 1617780229.196446 IP 10.104.255.30 > 172.29.62.100: ICMP echo request, id 937, seq 1, length 64 1617780229.197263 IP 172.29.62.100 > 10.104.255.30: ICMP echo reply, id 937, seq 1, length 64 perf out: ping 857 [000] 2609.657231: fib:fib_table_lookup: table 255 oif 6 iif 1 proto 17 0.0.0.0/53012 -> 172.29.62.100/1025 tos 0 scope 0 flags 4 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11 ping 857 [000] 2609.657234: fib:fib_table_lookup: table 10 oif 6 iif 1 proto 17 0.0.0.0/53012 -> 172.29.62.100/1025 tos 0 scope 0 flags 4 ==> dev green gw 0.0.0.0 src 10.104.255.30 err 0 ping 857 [000] 2609.657235: fib:fib_table_lookup: table 255 oif 6 iif 1 proto 17 10.104.255.30/53012 -> 172.29.62.100/1025 tos 0 scope 0 flags 4 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11 ping 857 [000] 2609.657236: fib:fib_table_lookup: table 10 oif 6 iif 1 proto 17 10.104.255.30/53012 -> 172.29.62.100/1025 tos 0 scope 0 flags 4 ==> dev green gw 0.0.0.0 src 10.104.255.30 err 0 ping 857 [000] 2609.659176: fib:fib_table_lookup: table 255 oif 6 iif 1 proto 1 0.0.0.0/0 -> 172.29.62.100/0 tos 0 scope 0 flags 4 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11 ping 857 [000] 2609.659178: fib:fib_table_lookup: table 10 oif 6 iif 1 proto 1 0.0.0.0/0 -> 172.29.62.100/0 tos 0 scope 0 flags 4 ==> dev green gw 0.0.0.0 src 10.104.255.30 err 0 ping 857 [000] 2609.659186: fib:fib_table_lookup: table 255 oif 7 iif 1 proto 1 10.104.255.30/0 -> 172.29.62.100/0 tos 0 scope 0 flags 5 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11 ping 857 [000] 2609.659188: fib:fib_table_lookup: table 20 oif 7 iif 1 proto 1 10.104.255.30/0 -> 172.29.62.100/0 tos 0 scope 0 flags 5 ==> dev eth0.10 gw 10.104.255.29 src 10.104.255.30 err 0 On Mon, Mar 29, 2021 at 10:58 PM manuel wolfshant wrote: > From rpetre at gmail.com Fri Apr 9 20:20:32 2021 From: rpetre at gmail.com (=?UTF-8?B?UGV0cnUgUmHIm2l1?=) Date: Fri, 9 Apr 2021 20:20:32 +0300 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: <5EED75A3-C480-4794-BB00-2CDA4F606EA8@gmail.com> References: <5EED75A3-C480-4794-BB00-2CDA4F606EA8@gmail.com> Message-ID: Nu mi-e foarte clar la ce anume te referi, dar cred ca zici de variabile de mediu. Cum sunt ele interpretate tine de programul care se uita la ele (clientul de http/https). wget foloseste http_proxy si https_proxy in functie de schema url-ului. Amuzant, curl se uita la http_proxy si HTTPS_PROXY, pentru ca... motive. Posibil alti clienti sa foloseasca chestii similare pentru familiaritate, dar nu e un standard consistent. Paginile de manual sunt cea mai buna lamurire. Din punctul de vedere al proxy-ului, trebuie ca clientului ala sa i se permita explicit accesul, depinde iarasi de softul de proxy cum se face asta (de notat ca proxy pentru https inseamna doar ca face metoda CONNECT si tuneleaza TLS prin proxy fara ca proxy-ul sa stie altceva in afara de hostname, asta daca vrei sa pui acl-uri mai fancy). Iarasi, daca ai da mai multe detalii ce anume incerci sa faci ar fi ceva mai bine. -- P. On Wed, Apr 7, 2021 at 9:42 PM Iulian Roman wrote: > Poate cineva sa explice cat mai clar cand se foloseste una din variabile > si cand cealalta si mai ales care este diferenta in modul de conectare la > proxy server ? Este nevoie de configurare speciala la nivel de proxy pentru > asta ? Am vazut ca in multe exemple http_proxy si https_proxy sunt setate > fix la fel. In alte exemple http_proxy foloseste http si https_proxy > foloseste https , deci se pare ca e destula confuzie. > Am avut un lung debate pe tema asta si as fi foarte curios sa lamuresc > problema . Orice link sau documentatie relevanta sunt binevenite (am citit > cred majoritatea topicurilor de pe stackoverflow si am gasit numai jumatati > de raspunsuri). > As dori sa mentionez ca nu TLS proxy intercept ma intereseaza. > > > > > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > From iulian.roman at gmail.com Fri Apr 9 23:26:06 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Fri, 9 Apr 2021 22:26:06 +0200 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: > On 9 Apr 2021, at 19:22, Petru Ra?iu wrote: > > ?Nu mi-e foarte clar la ce anume te referi, dar cred ca zici de variabile de > mediu. exact > Cum sunt ele interpretate tine de programul care se uita la ele > (clientul de http/https). wget foloseste http_proxy si https_proxy in > functie de schema url-ului. Amuzant, curl se uita la http_proxy si > HTTPS_PROXY, pentru ca... motive. Posibil alti clienti sa foloseasca > chestii similare pentru familiaritate, dar nu e un standard consistent. > Paginile de manual sunt cea mai buna lamurire. > > Din punctul de vedere al proxy-ului, trebuie ca clientului ala sa i se > permita explicit accesul, depinde iarasi de softul de proxy cum se face > asta (de notat ca proxy pentru https inseamna doar ca face metoda CONNECT > si tuneleaza TLS prin proxy fara ca proxy-ul sa stie altceva in afara de > hostname, asta daca vrei sa pui acl-uri mai fancy). > > Iarasi, daca ai da mai multe detalii ce anume incerci sa faci ar fi ceva > mai bine. > Nu ma intereseaza sa fac ceva anume, e mai mult curiozitatea de a intelege cum functioneaza si mai ales de ce si cand e indicat sa se foloseasca https_proxy. Totul a pornit de la o discutie cu un coleg cand testam conectarea prin Bluecoat (care are rolul de proxy) si l-am intrebat de ce are setat https_proxy iar el a raspuns ca http_proxy e pentru trafic http si https_proxy pentru trafic https , ceea ce nu are sens. Apoi am incercat sa caut pe net explicatii dar nu am gasit ceva foarte concret. Daca am setat http_proxy si https_proxy, cum se face conectarea clientului la proxy ? Inteleg ca depinde de client ? In concluzie , la ce ma ajuta https_proxy si cand e indicat de folosit , ca eu nu prea inteleg de ce ar trebui utilizat (in special in intranet) ? > -- > P. > >> On Wed, Apr 7, 2021 at 9:42 PM Iulian Roman wrote: >> >> Poate cineva sa explice cat mai clar cand se foloseste una din variabile >> si cand cealalta si mai ales care este diferenta in modul de conectare la >> proxy server ? Este nevoie de configurare speciala la nivel de proxy pentru >> asta ? Am vazut ca in multe exemple http_proxy si https_proxy sunt setate >> fix la fel. In alte exemple http_proxy foloseste http si https_proxy >> foloseste https , deci se pare ca e destula confuzie. >> Am avut un lung debate pe tema asta si as fi foarte curios sa lamuresc >> problema . Orice link sau documentatie relevanta sunt binevenite (am citit >> cred majoritatea topicurilor de pe stackoverflow si am gasit numai jumatati >> de raspunsuri). >> As dori sa mentionez ca nu TLS proxy intercept ma intereseaza. >> >> >> >> >> _______________________________________________ >> RLUG mailing list >> RLUG at lists.lug.ro >> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro >> > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro From rpetre at gmail.com Fri Apr 9 23:55:14 2021 From: rpetre at gmail.com (=?UTF-8?B?UGV0cnUgUmHIm2l1?=) Date: Fri, 9 Apr 2021 23:55:14 +0300 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: On Fri, Apr 9, 2021 at 11:27 PM Iulian Roman wrote: > > > > On 9 Apr 2021, at 19:22, Petru Ra?iu wrote: > > > > ?Nu mi-e foarte clar la ce anume te referi, dar cred ca zici de > variabile de > > mediu. > exact > > Cum sunt ele interpretate tine de programul care se uita la ele > > (clientul de http/https). wget foloseste http_proxy si https_proxy in > > functie de schema url-ului. Amuzant, curl se uita la http_proxy si > > HTTPS_PROXY, pentru ca... motive. Posibil alti clienti sa foloseasca > > chestii similare pentru familiaritate, dar nu e un standard consistent. > > Paginile de manual sunt cea mai buna lamurire. > > > > Din punctul de vedere al proxy-ului, trebuie ca clientului ala sa i se > > permita explicit accesul, depinde iarasi de softul de proxy cum se face > > asta (de notat ca proxy pentru https inseamna doar ca face metoda CONNECT > > si tuneleaza TLS prin proxy fara ca proxy-ul sa stie altceva in afara de > > hostname, asta daca vrei sa pui acl-uri mai fancy). > > > > Iarasi, daca ai da mai multe detalii ce anume incerci sa faci ar fi ceva > > mai bine. > > > Nu ma intereseaza sa fac ceva anume, e mai mult curiozitatea de a intelege > cum functioneaza si mai ales de ce si cand e indicat sa se foloseasca > https_proxy. Totul a pornit de la o discutie cu un coleg cand testam > conectarea prin Bluecoat (care are rolul de proxy) si l-am intrebat de ce > are setat https_proxy iar el a raspuns ca http_proxy e pentru trafic http > si https_proxy pentru trafic https , ceea ce nu are sens. Apoi am incercat > sa caut pe net explicatii dar nu am gasit ceva foarte concret. > Daca am setat http_proxy si https_proxy, cum se face conectarea clientului > la proxy ? Inteleg ca depinde de client ? > In concluzie , la ce ma ajuta https_proxy si cand e indicat de folosit , > ca eu nu prea inteleg de ce ar trebui utilizat (in special in intranet) ? > > Repet, tine de client. Programul pe care-l folosesti poate alege sa ia setari de proxy din env. Probabil ca colegul folosea ceva bazat pe wget, caz in care era perfect corecta explicatia. wget tine cont de schema url-ului de conectare si verifica daca exista setare de proxy pentru protocolul ala. La HTTP se leaga la portul cu pricina si face requestul normal, urmand ca proxy-ul sa se prinda din headerul Host cu cine voia sa vorbeasca de fapt si sa faca requestul mai departe. La HTTPS se leaga la server si face CONNECT realhost:443 (sau whatever), iar proxy-ul trateaza conexiunea ca pe un tunel TCP prin care clientul cu serverul vorbesc TLS ce le trazneste. Dar cum anume se cheama variabilele alea, tine de toanele clientului, lucru pe care doar din documentatia lui poti afla. Din manpage-ul de wget: Wget supports proxies for both HTTP and FTP retrievals. The > standard way to specify proxy location, which Wget recognizes, is using the > following environment variables: > > `http_proxy' `https_proxy' If set, the `http_proxy' and > `https_proxy' variables should contain the URLs of the proxies for HTTP and > HTTPS connections respectively. > > `ftp_proxy' This variable should contain the URL of the proxy for > FTP connections. It is quite common that `http_proxy' and `ftp_proxy' are > set to the same URL. > > `no_proxy' This variable should contain a comma-separated list of > domain extensions proxy should _not_ be used for. For instance, if the > value of `no_proxy' is `.mit.edu', proxy > will not be used to retrieve documents from MIT. > Din manpage de curl: ENVIRONMENT > The environment variables can be specified in lower case or upper > case. The lower case version has precedence. http_proxy is an exception as > it is only available in lower case. > > http_proxy [protocol://][:port] > Sets the proxy server to use for HTTP. > > HTTPS_PROXY [protocol://][:port] > Sets the proxy server to use for HTTPS. > > FTP_PROXY [protocol://][:port] > Sets the proxy server to use for FTP. > > ALL_PROXY [protocol://][:port] > Sets the proxy server to use if no protocol-specific proxy > is set. > > NO_PROXY > list of host names that shouldn't go through any proxy. If > set to a asterisk '*' only, it matches all hosts. > Alte programe pot alege sa se uite la variabilele astea sau altele sau sa vrea via config/command line. In general un client care e multi-protocol poate avea setari diferite pe fiecare protocol, pentru ca mecanismul e dependent de protocol oricum. Daca te uiti si in setarile browserului grafic ai setari diferite. E drept ca in ziua de azi cam tot traficul e https, dar asta e cu totul alta discutie. Bafta, -- P. From cave at cernat.ro Sat Apr 10 10:13:49 2021 From: cave at cernat.ro (Alex 'CAVE' Cernat) Date: Sat, 10 Apr 2021 10:13:49 +0300 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: <40becdee-293b-c17f-5a18-589769ea86b7@cernat.ro> On 09-Apr-21 23:26, Iulian Roman wrote: > Nu ma intereseaza sa fac ceva anume, e mai mult curiozitatea de a intelege cum functioneaza si mai ales de ce si cand e indicat sa se foloseasca https_proxy. Totul a pornit de la o discutie cu un coleg cand testam conectarea prin Bluecoat (care are rolul de proxy) si l-am intrebat de ce are setat https_proxy iar el a raspuns ca http_proxy e pentru trafic http si https_proxy pentru trafic https , ceea ce nu are sens. Apoi am incercat sa caut pe net explicatii dar nu am gasit ceva foarte concret. > Daca am setat http_proxy si https_proxy, cum se face conectarea clientului la proxy ? Inteleg ca depinde de client ? > In concluzie , la ce ma ajuta https_proxy si cand e indicat de folosit , ca eu nu prea inteleg de ce ar trebui utilizat (in special in intranet) ? gandeste-te la urmatoarea paralela: pe geamuri ai niste setari de exploder de proxy-uri (care de fapt sunt cumva "globale"); lasand la o parte exploderul, firefoxul are (sau cel putin avea ultima data cand m-am uitat) propriile setari de proxy, disponibile strict in aplicatie; in schimb chrome-ul le foloseste pe cele de exploder (aka cele "globale") la fel si pe linux au aparut (deja e istorie) acele setari de proxy (http_proxy si apoi https_proxy) care nu sunt nicaieri batute in cuie, insa le poti privi ca "best practices", iar in ziua de astazi orice aplicatie care se respecta ar trebui sa tina seama de ele, dar dupa cum spuneam nu este obligatoriu de ce sunt setari separate pentru normal si secure ? cred ca in primul rand pentru usurinta in configurare, pentru ca asa cum ti-a zis si Petru, proxy-ing-ul de https e un pic mai cu mot, lucrand (dincolo de stabilirea conexiunii) mai mult la level 4 decat la level 7 (asa cum e http-ul simplu); in plus e posibil (dar nu am dovezi si iarasi depinde de implementarea clientului) ca sa faca fallback la http_proxy atunci cand https_proxy nu e definit (dar daca proxy-ul nu suporta connect, atunci ghinion, o sa dea cu virgula) Alex From iulian.roman at gmail.com Sat Apr 10 10:34:30 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Sat, 10 Apr 2021 09:34:30 +0200 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: <2CA6812C-19D3-4510-8F5D-2C0BA8C19DB6@gmail.com> > On 9 Apr 2021, at 22:57, Petru Ra?iu wrote: > > ?On Fri, Apr 9, 2021 at 11:27 PM Iulian Roman wrote: > >> >> >>>> On 9 Apr 2021, at 19:22, Petru Ra?iu wrote: >>> >>> ?Nu mi-e foarte clar la ce anume te referi, dar cred ca zici de >> variabile de >>> mediu. >> exact >>> Cum sunt ele interpretate tine de programul care se uita la ele >>> (clientul de http/https). wget foloseste http_proxy si https_proxy in >>> functie de schema url-ului. Amuzant, curl se uita la http_proxy si >>> HTTPS_PROXY, pentru ca... motive. Posibil alti clienti sa foloseasca >>> chestii similare pentru familiaritate, dar nu e un standard consistent. >>> Paginile de manual sunt cea mai buna lamurire. >>> >>> Din punctul de vedere al proxy-ului, trebuie ca clientului ala sa i se >>> permita explicit accesul, depinde iarasi de softul de proxy cum se face >>> asta (de notat ca proxy pentru https inseamna doar ca face metoda CONNECT >>> si tuneleaza TLS prin proxy fara ca proxy-ul sa stie altceva in afara de >>> hostname, asta daca vrei sa pui acl-uri mai fancy). >>> >>> Iarasi, daca ai da mai multe detalii ce anume incerci sa faci ar fi ceva >>> mai bine. >>> >> Nu ma intereseaza sa fac ceva anume, e mai mult curiozitatea de a intelege >> cum functioneaza si mai ales de ce si cand e indicat sa se foloseasca >> https_proxy. Totul a pornit de la o discutie cu un coleg cand testam >> conectarea prin Bluecoat (care are rolul de proxy) si l-am intrebat de ce >> are setat https_proxy iar el a raspuns ca http_proxy e pentru trafic http >> si https_proxy pentru trafic https , ceea ce nu are sens. Apoi am incercat >> sa caut pe net explicatii dar nu am gasit ceva foarte concret. >> Daca am setat http_proxy si https_proxy, cum se face conectarea clientului >> la proxy ? Inteleg ca depinde de client ? >> In concluzie , la ce ma ajuta https_proxy si cand e indicat de folosit , >> ca eu nu prea inteleg de ce ar trebui utilizat (in special in intranet) ? >> >> > Repet, tine de client. Programul pe care-l folosesti poate alege sa ia > setari de proxy din env. Probabil ca colegul folosea ceva bazat pe wget, > caz in care era perfect corecta explicatia. exemplu era pentru curl, ceva de genul: HTTPS_PROXY=http://proxy.server:8080/ curl -fI https://twitter.com nedumerirea mea venea din faptul ca ambele variabile (http_proxy si https_proxy) erau setate la fel (http://proxy.server:8080/) si nu intelegeam cum se poate face accessul la proxy diferit. Daca am inteles eu corect, https_proxy nu inseamna ca am un tunel tls intre client si proxy si altul intre proxy si upstream (adica tls termination la nivel de proxy) ci se face doar un connect intre proxy si upstream prin care se redirectioneaza traficul dintre client si upstream (care era oricum TLS). Ce se intimpla daca am numai https_proxy setat pe un server ? Inseamna ca tot ce e https iese prin proxy si http nu ? Pentru ca in cazul in care am setat numai http_proxy ambele tipuri de trafic sunt permise. > wget tine cont de schema > url-ului de conectare si verifica daca exista setare de proxy pentru > protocolul ala. La HTTP se leaga la portul cu pricina si face requestul > normal, urmand ca proxy-ul sa se prinda din headerul Host cu cine voia sa > vorbeasca de fapt si sa faca requestul mai departe. La HTTPS se leaga la > server si face CONNECT realhost:443 (sau whatever), iar proxy-ul trateaza > conexiunea ca pe un tunel TCP prin care clientul cu serverul vorbesc TLS ce > le trazneste. In concluzie , singurul lucru de care ma protejeaza https_proxy este un tls intercept intre proxy si upstream (oriunde ar putea sa se intimple) ? > Dar cum anume se cheama variabilele alea, tine de toanele > clientului, lucru pe care doar din documentatia lui poti afla. > > Din manpage-ul de wget: > > Wget supports proxies for both HTTP and FTP retrievals. The >> standard way to specify proxy location, which Wget recognizes, is using the >> following environment variables: >> >> `http_proxy' `https_proxy' If set, the `http_proxy' and >> `https_proxy' variables should contain the URLs of the proxies for HTTP and >> HTTPS connections respectively. >> >> `ftp_proxy' This variable should contain the URL of the proxy for >> FTP connections. It is quite common that `http_proxy' and `ftp_proxy' are >> set to the same URL. >> >> `no_proxy' This variable should contain a comma-separated list of >> domain extensions proxy should _not_ be used for. For instance, if the >> value of `no_proxy' is `.mit.edu', proxy >> will not be used to retrieve documents from MIT. >> > > Din manpage de curl: > > ENVIRONMENT >> The environment variables can be specified in lower case or upper >> case. The lower case version has precedence. http_proxy is an exception as >> it is only available in lower case. >> >> http_proxy [protocol://][:port] >> Sets the proxy server to use for HTTP. >> >> HTTPS_PROXY [protocol://][:port] >> Sets the proxy server to use for HTTPS. >> >> FTP_PROXY [protocol://][:port] >> Sets the proxy server to use for FTP. >> >> ALL_PROXY [protocol://][:port] >> Sets the proxy server to use if no protocol-specific proxy >> is set. >> >> NO_PROXY >> list of host names that shouldn't go through any proxy. If >> set to a asterisk '*' only, it matches all hosts. >> > > > Alte programe pot alege sa se uite la variabilele astea sau altele sau sa > vrea via config/command line. In general un client care e multi-protocol > poate avea setari diferite pe fiecare protocol, pentru ca mecanismul e > dependent de protocol oricum. Daca te uiti si in setarile browserului > grafic ai setari diferite. E drept ca in ziua de azi cam tot traficul e > https, dar asta e cu totul alta discutie > > Bafta, Multumesc pentru explicatii > > -- > P. > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro From iulian.roman at gmail.com Sat Apr 10 10:47:42 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Sat, 10 Apr 2021 09:47:42 +0200 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: <40becdee-293b-c17f-5a18-589769ea86b7@cernat.ro> References: <40becdee-293b-c17f-5a18-589769ea86b7@cernat.ro> Message-ID: <46068B15-0409-452B-AA00-572802E96357@gmail.com> > On 10 Apr 2021, at 09:15, Alex 'CAVE' Cernat wrote: > > ?On 09-Apr-21 23:26, Iulian Roman wrote: >> Nu ma intereseaza sa fac ceva anume, e mai mult curiozitatea de a intelege cum functioneaza si mai ales de ce si cand e indicat sa se foloseasca https_proxy. Totul a pornit de la o discutie cu un coleg cand testam conectarea prin Bluecoat (care are rolul de proxy) si l-am intrebat de ce are setat https_proxy iar el a raspuns ca http_proxy e pentru trafic http si https_proxy pentru trafic https , ceea ce nu are sens. Apoi am incercat sa caut pe net explicatii dar nu am gasit ceva foarte concret. >> Daca am setat http_proxy si https_proxy, cum se face conectarea clientului la proxy ? Inteleg ca depinde de client ? >> In concluzie , la ce ma ajuta https_proxy si cand e indicat de folosit , ca eu nu prea inteleg de ce ar trebui utilizat (in special in intranet) ? > > gandeste-te la urmatoarea paralela: pe geamuri ai niste setari de > exploder de proxy-uri (care de fapt sunt cumva "globale"); lasand la o > parte exploderul, firefoxul are (sau cel putin avea ultima data cand > m-am uitat) propriile setari de proxy, disponibile strict in aplicatie; > in schimb chrome-ul le foloseste pe cele de exploder (aka cele "globale") > la fel si pe linux au aparut (deja e istorie) acele setari de proxy > (http_proxy si apoi https_proxy) care nu sunt nicaieri batute in cuie, > insa le poti privi ca "best practices", iar in ziua de astazi orice > aplicatie care se respecta ar trebui sa tina seama de ele, dar dupa cum > spuneam nu este obligatoriu > de ce sunt setari separate pentru normal si secure ? cred ca in primul > rand pentru usurinta in configurare, pentru ca asa cum ti-a zis si > Petru, proxy-ing-ul de https e un pic mai cu mot, lucrand (dincolo de > stabilirea conexiunii) mai mult la level 4 decat la level 7 (asa cum e > http-ul simplu); aici probabil ca e diferenta, pentru ca daca https_proxy e exclusiv folosit pentru trafic https (care oricum e encrypted intre client si end server) , la ce ma ajuta ? Asa cum am spus in celalat reply singura masura de extra-protectie este un eventual intercept intre proxy si end server (ceea ce nu e chiar rau). > in plus e posibil (dar nu am dovezi si iarasi depinde > de implementarea clientului) ca sa faca fallback la http_proxy atunci > cand https_proxy nu e definit (dar daca proxy-ul nu suporta connect, > atunci ghinion, o sa dea cu virgula) > > Alex > > > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro From cave at cernat.ro Sat Apr 10 11:16:21 2021 From: cave at cernat.ro (Alex 'CAVE' Cernat) Date: Sat, 10 Apr 2021 11:16:21 +0300 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: <46068B15-0409-452B-AA00-572802E96357@gmail.com> References: <40becdee-293b-c17f-5a18-589769ea86b7@cernat.ro> <46068B15-0409-452B-AA00-572802E96357@gmail.com> Message-ID: On 10-Apr-21 10:47, Iulian Roman wrote: > aici probabil ca e diferenta, pentru ca daca https_proxy e exclusiv folosit pentru trafic https (care oricum e encrypted intre client si end server) , la ce ma ajuta ? Asa cum am spus in celalat reply singura masura de extra-protectie este un eventual intercept intre proxy si end server (ceea ce nu e chiar rau). sincer nu prea inteleg intrebarea, dar o sa incerc sa raspund la ce cred ca ai vrut sa intrebi luand-o de la traian si decebal, proxy-urile au fost "inventate" pentru doua chestii: caching (pe vremea cand banda era ceva scump al naibii) si apoi posibilitatea de a stabili niste acl-uri (in special prin mediile enterprise); apoi s-a adaugat si posibilitatea de a inspecta traficul (virusi & stuff); dupa "explozia" de https in ultimii ani si-au mai pierdut din "stralucire", filtrarea fiind mult mai limitata (desigur, exista tls interceptors, dar daca stai bine sa te gandesti ele reprezinta o violare a ceea ce inseamna https in sine) dupa umila mea parere proxy-urile intra in prezent la ceea ce am putea numi "legacy"; vor mai ramane cu noi destule decenii, dar epoca lor de glorie a cam apus Alex From iulian.roman at gmail.com Sat Apr 10 11:31:57 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Sat, 10 Apr 2021 10:31:57 +0200 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: > On 10 Apr 2021, at 10:18, Alex 'CAVE' Cernat wrote: > > ?On 10-Apr-21 10:47, Iulian Roman wrote: >> aici probabil ca e diferenta, pentru ca daca https_proxy e exclusiv folosit pentru trafic https (care oricum e encrypted intre client si end server) , la ce ma ajuta ? Asa cum am spus in celalat reply singura masura de extra-protectie este un eventual intercept intre proxy si end server (ceea ce nu e chiar rau). > > sincer nu prea inteleg intrebarea, dar o sa incerc sa raspund la ce cred > ca ai vrut sa intrebi > > luand-o de la traian si decebal, proxy-urile au fost "inventate" pentru > doua chestii: caching (pe vremea cand banda era ceva scump al naibii) si > apoi posibilitatea de a stabili niste acl-uri (in special prin mediile > enterprise); apoi s-a adaugat si posibilitatea de a inspecta traficul > (virusi & stuff); dupa "explozia" de https in ultimii ani si-au mai > pierdut din "stralucire", filtrarea fiind mult mai limitata (desigur, > exista tls interceptors, dar daca stai bine sa te gandesti ele > reprezinta o violare a ceea ce inseamna https in sine) dar din pacate asta se intimpla (mai frecvent decit vrem sa credem ) , ceea ce e destul de ingrijorator ! si toata chestia cu protectia TLS devine debatable , dar asta e o total alta discutie. > > dupa umila mea parere proxy-urile intra in prezent la ceea ce am putea > numi "legacy"; vor mai ramane cu noi destule decenii, dar epoca lor de > glorie a cam apus > > Alex > > > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro From cave at cernat.ro Sat Apr 10 11:59:21 2021 From: cave at cernat.ro (Alex 'CAVE' Cernat) Date: Sat, 10 Apr 2021 11:59:21 +0300 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: <8f1fe474-3ef0-1267-8bb8-ef58361cfd1b@cernat.ro> On 10-Apr-21 11:31, Iulian Roman wrote: > dar din pacate asta se intimpla (mai frecvent decit vrem sa credem ) , ceea ce e destul de ingrijorator ! si toata chestia cu protectia TLS devine debatable , dar asta e o total alta discutie. pentru ca tls interception sa functioneze din ce stiu trebuie in primul rand ca cineva sa-ti bage pe gat pe device un CA (nu ca ar fi mare branza in mediul enterprise, mai mult, au fost si cazuri - cu mare scandal - la nivel de tari intregi) si cum lista de CA-uri a ajuns mare cat o zi de post, cine sta oare sa se uite de fiecare data sa vada ce "gunoaie" au mai aparut pe acolo? certificate pinning complica mult prea mult treaba, mai ales ca din ce in ce mai multa lume foloseste letsencrypt, caa-ul din dns e o solutie interesanta, insa nu stiu exact cat suport are (sa fim seriosi, nici macar partea de revocation nu stiu cat de serios e tratata de browsere, noroc cu letsencrypt ca expira dupa 3 luni automat :-P) Alex From rpetre at gmail.com Sat Apr 10 12:02:58 2021 From: rpetre at gmail.com (=?UTF-8?B?UGV0cnUgUmHIm2l1?=) Date: Sat, 10 Apr 2021 12:02:58 +0300 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: <2CA6812C-19D3-4510-8F5D-2C0BA8C19DB6@gmail.com> References: <2CA6812C-19D3-4510-8F5D-2C0BA8C19DB6@gmail.com> Message-ID: On Sat, Apr 10, 2021 at 10:35 AM Iulian Roman wrote: > > > > wget tine cont de schema > > url-ului de conectare si verifica daca exista setare de proxy pentru > > protocolul ala. La HTTP se leaga la portul cu pricina si face requestul > > normal, urmand ca proxy-ul sa se prinda din headerul Host cu cine voia sa > > vorbeasca de fapt si sa faca requestul mai departe. La HTTPS se leaga la > > server si face CONNECT realhost:443 (sau whatever), iar proxy-ul trateaza > > conexiunea ca pe un tunel TCP prin care clientul cu serverul vorbesc TLS > ce > > le trazneste. > > In concluzie , singurul lucru de care ma protejeaza https_proxy este un > tls intercept intre proxy si upstream (oriunde ar putea sa se intimple) ? > > Ok, eu cred ca tu ai in cap o ciorba cu toate notiunile astea si intrebarile pe care le pui explicit au doar vaga legatura cu ce probleme ai de fapt. Nimeni nu protejeaza pe nimeni de nimic, nimeni nu ataca pe nimeni cu nimic (cel putin implicit). Mecanismul de proxy exista doar ca sa permita unui device intermediar sa faca relay requestului la nivel de layer 7. La ce folosesti asta depinde foarte mult de contextul implementarii. Acu daca lucrezi cu bluecoaturi probabil asociezi asta cu tot felul de aspecte de security dar povestile cu capa si spada sunt complet detasate de cum functioneaza lucrurile. Iar variabilele de mediu sunt pur si simplu un mod de a configura programele pe care le folosesti, nu-s vraji de protectie sau altceva. Incearca sa reformulezi mai bine problema pe care o ai (sau, mai bine, mai citeste putin despre conceptele implicate si reformuleaza cand s-a mai cristalizat) si mai vedem. -- P. From iulian.roman at gmail.com Sat Apr 10 12:10:19 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Sat, 10 Apr 2021 11:10:19 +0200 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: <8f1fe474-3ef0-1267-8bb8-ef58361cfd1b@cernat.ro> References: <8f1fe474-3ef0-1267-8bb8-ef58361cfd1b@cernat.ro> Message-ID: <6C88AAB4-6DD1-48AB-B5CE-D1E2935C978E@gmail.com> > On 10 Apr 2021, at 11:01, Alex 'CAVE' Cernat wrote: > > ?On 10-Apr-21 11:31, Iulian Roman wrote: >> dar din pacate asta se intimpla (mai frecvent decit vrem sa credem ) , ceea ce e destul de ingrijorator ! si toata chestia cu protectia TLS devine debatable , dar asta e o total alta discutie. > > pentru ca tls interception sa functioneze din ce stiu trebuie in primul > rand ca cineva sa-ti bage pe gat pe device un CA (nu ca ar fi mare > branza in mediul enterprise, mai mult, au fost si cazuri - cu mare > scandal - la nivel de tari intregi) exact. a fost un mare scandal acu ceva ani cand Bluecoat a reusit sa semneze intermediate CA-ul din echipamentele lor cu un trusted root ca. > > si cum lista de CA-uri a ajuns mare cat o zi de post, cine sta oare sa > se uite de fiecare data sa vada ce "gunoaie" au mai aparut pe acolo? > > certificate pinning complica mult prea mult treaba, mai ales ca din ce > in ce mai multa lume foloseste letsencrypt, caa-ul din dns e o solutie > interesanta, insa nu stiu exact cat suport are (sa fim seriosi, nici > macar partea de revocation nu stiu cat de serios e tratata de browsere, > noroc cu letsencrypt ca expira dupa 3 luni automat :-P) si aici e u mare mess se pare, sa nu mai vorbim de cum se face validarea tls de non-browser software (am citit un studiu care explica ce urechist se face validarea tls in non-browsers, inclusiv la big players). > > Alex > > > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro From iulian.roman at gmail.com Sat Apr 10 12:29:44 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Sat, 10 Apr 2021 11:29:44 +0200 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: > On 10 Apr 2021, at 11:04, Petru Ra?iu wrote: > > ?On Sat, Apr 10, 2021 at 10:35 AM Iulian Roman > wrote: > >> >> >>> wget tine cont de schema >>> url-ului de conectare si verifica daca exista setare de proxy pentru >>> protocolul ala. La HTTP se leaga la portul cu pricina si face requestul >>> normal, urmand ca proxy-ul sa se prinda din headerul Host cu cine voia sa >>> vorbeasca de fapt si sa faca requestul mai departe. La HTTPS se leaga la >>> server si face CONNECT realhost:443 (sau whatever), iar proxy-ul trateaza >>> conexiunea ca pe un tunel TCP prin care clientul cu serverul vorbesc TLS >> ce >>> le trazneste. >> >> In concluzie , singurul lucru de care ma protejeaza https_proxy este un >> tls intercept intre proxy si upstream (oriunde ar putea sa se intimple) ? >> >> > Ok, eu cred ca tu ai in cap o ciorba cu toate notiunile astea si > intrebarile pe care le pui explicit au doar vaga legatura cu ce probleme ai > de fapt. este posibil; nu am o problema , e numai o curiozitate (sau poate nu stiu ca am o problema). singurul lucru care ma intereseaza este de ce ar trebui sa folosesc https_proxy in loc de http_proxy , pentru ca presupun ca nu e numai o chestie cosmetica. > > Nimeni nu protejeaza pe nimeni de nimic, nimeni nu ataca pe nimeni cu nimic > (cel putin implicit). Mecanismul de proxy exista doar ca sa permita unui > device intermediar sa faca relay requestului la nivel de layer 7. asta am inteles, ce nu am inteles era de ce si cum se face relay-ul in functie de tipul de variabila de mediu folosit in client. Dar acum cred ca a devenit mult mai clar, si poate lamuritor ar fi cand fac niste tcpdump la trafic. > La ce > folosesti asta depinde foarte mult de contextul implementarii. > Acu daca > lucrezi cu bluecoaturi probabil asociezi asta cu tot felul de aspecte de > security dar povestile cu capa si spada sunt complet detasate de cum > functioneaza lucrurile. da, s-ar putea sa vad lucrurile prin prisma bluecoat-ului, cum altii le-ar putea vedea prin prisma squid-ului. din punctul meu de vedere, orice end client care functioneaza ca si http client si face uz de variabilele de mediu din linux nu ar trebui sa faca nici o diferenta intre tipul de proxy la care se conecteaza (si probabil nu face) > > Iar variabilele de mediu sunt pur si simplu un mod de a configura > programele pe care le folosesti, nu-s vraji de protectie sau altceva. dar in functie de ele, programele se comporta diferit si asta inseamna moduri se securitate diferite ! > Incearca sa reformulezi mai bine problema pe care o ai (sau, mai bine, mai > citeste putin despre conceptele implicate si reformuleaza cand s-a mai > cristalizat) si mai vedem. dupa cum am explicat, nu am o problema , este numai o curiozitate . bucuros sa citessc orice documenatie relevanta, dar pina acum nu am gasit ceva multumitor si citeodata un brainstorming / debate cu oamenii care au ceva de explicat ajuta foarte mult. in cazul de fata a ajutat . > > -- > P. > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro From rpetre at gmail.com Sat Apr 10 12:48:23 2021 From: rpetre at gmail.com (=?UTF-8?B?UGV0cnUgUmHIm2l1?=) Date: Sat, 10 Apr 2021 12:48:23 +0300 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: Bun, mai incerc o data. Daca alegi sa folosesti un proxy, ar trebui sa stii de ce. Poate reteaua in care esti nu are acces direct la internet decat asa sau poate vrei sa accesezi serverul cu pricina de la alt IP. Sau poate cineva rau ti-a facut takeover pe computer si incearca sa-ti pacaleasca clientul sa trimita traficul in alta parte. Interpretarea de securitate nu tine de mecanism in sine, trebuie doar sa intelegi cum functioneaza si apoi sa decizi daca vrei sau nu vrei asta. Variabilele de care intrebai initial tin de apucaturile clientului in sine (aparent nu prea ai confirmat ca ai inteles diferenta). E posibil sa am un program care se uita dupa variabila MY_FANCY_PROXY si sa ignore complet altele. Ce trebuie sa stii este ca e o actiune pe care programul o ia explicit si mecanismul difera in functie de protocol. unele din povestile enumerate mai sus in thread nu au sens decat in scenariul de transparent proxy, cand clientul nu face nimic special, se conecteaza in mod normal, dar un router pe drum ia streamul TCP si-l redirecteaza in proxy, care la randul lui trebuie sa stie ca clientul nu coopereaza si trebuie sa se descurce singur (aici incep sa devieze mult mai tare mecanismele pt tls si non-tls traffic, dar deviem de la subiect). Revenind la proxy explicit, atat clientul cat si proxy-ul fac lucruri diferite pentru http si https, asa ca asta cumva justifica sa ai configurari separate (desi in general se foloseste acelasi device ca proxy pentru ambele din ratiuni de convenienta). Ultima intrebare la care mai raspund, "la ce ma mai ajuta https_proxy daca proxy-ul oricum nu vede nimic?" Simplu, ca sa mearga :) Ultima oara cand m-am uitat, wget nu se uita la http_proxy pentru url-uri care incepeau cu https, si daca adminul retelei locale nu te lasa din firewall sa iesi pe 443 prin default gateway ci trebuie sa folosesti explicit proxy (din ce motive, depinde de la caz la caz, poate asa i s-a nazarit), n-o sa mearga. Aia cu validarea tls e alt can of worms,si "urechismul" tine mai adesea de asteptarile pe care le ai, sunt surprinzator de multe aspecte pe care poti alege sa le faci diferit. -- P. From iulian.roman at gmail.com Sat Apr 10 13:21:03 2021 From: iulian.roman at gmail.com (Iulian Roman) Date: Sat, 10 Apr 2021 12:21:03 +0200 Subject: [rlug] http_proxy vs https_proxy In-Reply-To: References: Message-ID: <222DA96C-EDFF-4914-A4F4-0842AC3D599F@gmail.com> > On 10 Apr 2021, at 11:50, Petru Ra?iu wrote: > > ?Bun, mai incerc o data. Daca alegi sa folosesti un proxy, ar trebui sa stii > de ce. Poate reteaua in care esti nu are acces direct la internet decat asa > sau poate vrei sa accesezi serverul cu pricina de la alt IP. Sau poate > cineva rau ti-a facut takeover pe computer si incearca sa-ti pacaleasca > clientul sa trimita traficul in alta parte. Interpretarea de securitate nu > tine de mecanism in sine, trebuie doar sa intelegi cum functioneaza si apoi > sa decizi daca vrei sau nu vrei asta. > > Variabilele de care intrebai initial tin de apucaturile clientului in sine > (aparent nu prea ai confirmat ca ai inteles diferenta). E posibil sa am un > program care se uita dupa variabila MY_FANCY_PROXY si sa ignore complet > altele. Ce trebuie sa stii este ca e o actiune pe care programul o ia > explicit si mecanismul difera in functie de protocol. unele din povestile > enumerate mai sus in thread nu au sens decat in scenariul de transparent > proxy, cand clientul nu face nimic special, se conecteaza in mod normal, > dar un router pe drum ia streamul TCP si-l redirecteaza in proxy, care la > randul lui trebuie sa stie ca clientul nu coopereaza si trebuie sa se > descurce singur (aici incep sa devieze mult mai tare mecanismele pt tls si > non-tls traffic, dar deviem de la subiect). > > Revenind la proxy explicit, atat clientul cat si proxy-ul fac lucruri > diferite pentru http si https, asa ca asta cumva justifica sa ai > configurari separate (desi in general se foloseste acelasi device ca proxy > pentru ambele din ratiuni de convenienta). > > Ultima intrebare la care mai raspund, "la ce ma mai ajuta https_proxy daca > proxy-ul oricum nu vede nimic?" Simplu, ca sa mearga :) ok, deci numai ca sa eviti eventuale probleme cand nu stii exact care e behavior-ul clientului (daca face sau nu fallback la http) ; pentru mine nu are sens, dar i?ll take it as it is > Ultima oara cand > m-am uitat, wget nu se uita la http_proxy pentru url-uri care incepeau cu > https, si daca adminul retelei locale nu te lasa din firewall sa iesi pe > 443 prin default gateway ci trebuie sa folosesti explicit proxy (din ce > motive, depinde de la caz la caz, poate asa i s-a nazarit), n-o sa mearga. > asta e cazul in multe medii (cam toate in care am lucrat pina acum ) unde accessul se face explicit prin proxy (pentru ca aparent nu exista alta metoda eficienta de autentificare/filtrare/control al traficului) > Aia cu validarea tls e alt can of worms,si "urechismul" tine mai adesea de > asteptarile pe care le ai, sunt surprinzator de multe aspecte pe care poti > alege sa le faci diferit. daca aspectele din link-ul de mai jos sunt inca actuale , e scary https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf > > -- > P. > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro From andreimpopescu at gmail.com Mon Apr 12 11:36:13 2021 From: andreimpopescu at gmail.com (Andrei POPESCU) Date: Mon, 12 Apr 2021 11:36:13 +0300 Subject: [rlug] =?utf-8?q?Probleme_liste_lug=2Ero_cu_mesaje_la_=28=C8=99i?= =?utf-8?q?_de_la=3F=29_GMX?= Message-ID: <20210412083613.l5k2i5v2blzvjc74@acr13.nuvreauspam> Salut, Dup? postarea me pe offtopic am realizat c? nu am mai primit mesaje de la list? pe adresa de GMX din 14 dec (respectiv 28 dec de pe rlug). Adresa de Gmail e ?nscris? doar pentru postare, toate mesajele (ar trebuie s?) le primesc pe o adres? de GMX (pe care a? prefera s? nu o postez pe list?). Am ?ncercat s?-mi verific set?rile din mailman, dar nu mai am parola ?i n-am primit nimic nici c?nd am ?ncercat 'password reminder'. Am trimis un mesaj similar ?i de pe adresa de GMX la owner-offtopic@, dar m? g?ndesc c? e posibil s? nu fi ajuns. De pe adresa asta la mailman@ mi-a dat eroare (adres? inexistent?). La Debian sunt ?nscris pe vreo 10 liste ?i primesc mesajele de la liste ?n c?teva secunde. Spor, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Adrian.Sevcenco at cern.ch Tue Apr 13 21:29:59 2021 From: Adrian.Sevcenco at cern.ch (Adrian Sevcenco) Date: Tue, 13 Apr 2021 21:29:59 +0300 Subject: [rlug] dilema existentiala bash Message-ID: <7198a14d-b6ac-fa3a-92de-b9a18aef092d@cern.ch> Salutare! Am o dilema existentiala in acest moment si in seara asta google-fu-ul meu e slab: care e diferenta intre: bash -bla -c arg1 arg2 arg3 si bash -bla -- arg1 arg2 arg3 Are cineva idee? (baseline-ul de bash e 4.2.46) Multumesc! Adrian From catalin.muresan at gmail.com Tue Apr 13 21:35:44 2021 From: catalin.muresan at gmail.com (Catalin Muresan) Date: Tue, 13 Apr 2021 19:35:44 +0100 Subject: [rlug] dilema existentiala bash In-Reply-To: <7198a14d-b6ac-fa3a-92de-b9a18aef092d@cern.ch> References: <7198a14d-b6ac-fa3a-92de-b9a18aef092d@cern.ch> Message-ID: De obicei dupa parametrul -- poti pune parametri care incep cu - si care sa fie ignorati ca parametri -- A -- signals the end of options and disables further option processing. Any arguments after the -- are treated as filenames and arguments. An argument of - is equivalent to --. On Tue, 13 Apr 2021 at 19:31, Adrian Sevcenco wrote: > Salutare! Am o dilema existentiala in acest moment si in seara asta > google-fu-ul meu e slab: > care e diferenta intre: > bash -bla -c arg1 arg2 arg3 > si > bash -bla -- arg1 arg2 arg3 > > Are cineva idee? (baseline-ul de bash e 4.2.46) > > Multumesc! > Adrian > > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > From Adrian.Sevcenco at cern.ch Tue Apr 13 22:23:47 2021 From: Adrian.Sevcenco at cern.ch (Adrian Sevcenco) Date: Tue, 13 Apr 2021 22:23:47 +0300 Subject: [rlug] dilema existentiala bash In-Reply-To: References: <7198a14d-b6ac-fa3a-92de-b9a18aef092d@cern.ch> Message-ID: On 4/13/21 9:35 PM, Catalin Muresan wrote: > De obicei dupa parametrul -- poti pune parametri care incep cu - si care sa > fie ignorati ca parametri mda, prin incercari am gasit smecheria: -c arg1 arg2 arg3 arg2 si 3 sunt ignorati se executa doar arg1 daca se impacheteaza ca string -c "arg1 ar2 arg3" se executa ca si o comanda normala de bash pt bash -- arg1 arg2 arg3 arg1 (sau intregul string in cazul "arg1 arg2 arg3") e obligatoriu sa fie un fisier existent, _non-binar_ si interpretabil de bash deci inlocuieste shabang-ul cumva (cumva cum faci python fsdkfjs.py) Adrian > > -- A -- signals the end of options and disables further > option processing. Any arguments after the -- are treated as filenames and > arguments. An argument of - is equivalent to --. > > > On Tue, 13 Apr 2021 at 19:31, Adrian Sevcenco > wrote: > >> Salutare! Am o dilema existentiala in acest moment si in seara asta >> google-fu-ul meu e slab: >> care e diferenta intre: >> bash -bla -c arg1 arg2 arg3 >> si >> bash -bla -- arg1 arg2 arg3 >> >> Are cineva idee? (baseline-ul de bash e 4.2.46) >> >> Multumesc! >> Adrian >> >> _______________________________________________ >> RLUG mailing list >> RLUG at lists.lug.ro >> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro >> > _______________________________________________ > RLUG mailing list > RLUG at lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > -- ---------------------------------------------- Adrian Sevcenco, Ph.D. | Institute of Space Science - ISS, Romania | adrian.sevcenco at {cern.ch,spacescience.ro} | ----------------------------------------------