July 2014 - openSUSE Users - openSUSE Mailing Lists

[opensuse] SSL handshaking with optional client verification
by Ted Byers 31 Jul '14

31 Jul '14

Although I have SSL seeming to work, I have encountered another problem. I have written a small Perl package that tries to ensure that communication between client and server is properly handled. I made client verification optional on gremlin.site, and, in my test script, I provide the filename and the directory in which the client certificate is located to LWP's user agent.. Now, the usual printenv.pl prints out the environment, including any certificates that are exchanged. But when I run my script, I see the content of the server side certificate but the field that is supposed to hold the client side certificate is empty. How do I determine whether the fault is with the server not asking for the client certificate or the client not sending it? I guess I could tell Firefox and/or Chrome to use my client certificate, and then use them to access the same page, but I don't know how to tell browsers about client certificates. Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] 13.1 - NetworkManager - Can you prioritize connections?
by David C. Rankin 31 Jul '14

31 Jul '14

All, Using traditional ifup for wireless, wpa_supplicant.conf allowed you to prioritize wireless connections by ordering the entries within the file. NetworkManager does not rely on entries in wpa_supplicant.conf for wireless credentials, and thus that manner of prioritizing has gone away. man NetworkManager mentions only execution priority for "scripts in the /etc/NetworkManager/dispatcher.d directory in alphabetical order in response to network events", but is otherwise silent on connection priority. Can you prioritize wifi connections in NetworkManager so that if 5 connections are available, you can specify the one that it tried/used first? If so, how? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 4

[opensuse] 13.1 - zypper - strange results from zypper patch
by Rolf Krahl 31 Jul '14

31 Jul '14

Hi all Since yesterday, I get strange results from zypper patch: ---------- quote ---------- # zypper patch-check Loading repository data... Reading installed packages... 5 patches needed (3 security patches) # zypper list-patches Loading repository data... Reading installed packages... Repository | Name | Version | Category | Status | Summary ---------------------+----------------+---------+-------------+--------+-------- openSUSE-13.1-Update | openSUSE-2014- | 1 | recommended | needed | Image-> openSUSE-13.1-Update | openSUSE-2014- | 1 | security | needed | ntp: -> openSUSE-13.1-Update | openSUSE-2014- | 1 | recommended | needed | vorbi-> openSUSE-13.1-Update | openSUSE-2014- | 1 | security | needed | Mozil-> openSUSE-13.1-Update | openSUSE-2014- | 1 | security | needed | updat-> # zypper patch Loading repository data... Reading installed packages... Resolving package dependencies... Nothing to do. -------- end quote -------- How come, "zypper patch" got nothing to do if "zypper list-patches" lists 5 patches that need to get installed? Version info about concerned packages: ---------- quote ---------- # zypper info ImageMagick [...] Repository: openSUSE-13.1-Update Name: ImageMagick Version: 6.8.6.9-2.16.1 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: out-of-date (version 6.8.6.9-2.12.1 installed) # zypper info ntp [...] Repository: openSUSE-13.1-Update Name: ntp Version: 4.2.6p5-15.5.1 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: out-of-date (version 4.2.6p5-15.2.1 installed) # zypper info vorbis-tools [...] Repository: openSUSE-13.1-Update Name: vorbis-tools Version: 1.4.0-14.4.1 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: out-of-date (version 1.4.0-14.1.1 installed) # zypper info MozillaFirefox [...] Repository: openSUSE-13.1-Update Name: MozillaFirefox Version: 31.0-33.1 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: out-of-date (version 30.0-29.1 installed) # zypper info pulseaudio [...] Repository: openSUSE-13.1-Update Name: pulseaudio Version: 4.0.git.270.g9490a-12.1 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: out-of-date (version 4.0.git.270.g9490a-8.1 installed) -------- end quote -------- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 8

Re: [opensuse] Apache 2.4.6 on OpenSuse 13.1: ssl_error_rx_record_too_long and ERR_SSL_PROTOCOL_ERROR
by Ted Byers 31 Jul '14

31 Jul '14

On Wed, Jul 30, 2014 at 11:29 AM, Florian Gleixner <flo(a)redflo.de> wrote: > On 07/30/2014 03:47 PM, Ted Byers wrote: >> 140137415726736:error:140770FC:SSL >> routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:787: > > > I think you are talking HTTP and not HTTPS on port 443. Try to browse to > http://gremlin.site:443 to verify this. > > Check if you have configured apache to load SSL modules. Edit > /etc/sysconfig/apache2 and check if you have set: > > > APACHE_MODULES=".... ssl ...." > APACHE_SERVER_FLAGS="SSL" > > If this helps please post the solution to the list too :-) > Sorry. I sent my previous reply to the list once I noticed I had sent it only to you. Anyway, although ssl was in the list of modules, it wasn't in the apache_server_flags. I corrected that and now the server won't start: ted@gremlin:~/SSLwork> sudo systemctl status apache2.service -l apache2.service - The Apache Webserver Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled) Active: failed (Result: exit-code) since Wed 2014-07-30 11:50:07 EDT; 1min 50s ago Process: 12088 ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND -k graceful-stop (code=exited, status=0/SUCCESS) Process: 12069 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND -k start (code=exited, status=1/FAILURE) Main PID: 12069 (code=exited, status=1/FAILURE) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" Jul 30 11:50:06 gremlin start_apache2[12069]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:443 Jul 30 11:50:06 gremlin start_apache2[12069]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443 Jul 30 11:50:06 gremlin start_apache2[12069]: no listening sockets available, shutting down Jul 30 11:50:06 gremlin start_apache2[12069]: AH00015: Unable to open logs Jul 30 11:50:06 gremlin systemd[1]: apache2.service: main process exited, code=exited, status=1/FAILURE Jul 30 11:50:07 gremlin start_apache2[12088]: httpd (no pid file) not running Jul 30 11:50:07 gremlin systemd[1]: Failed to start The Apache Webserver. Jul 30 11:50:07 gremlin systemd[1]: Unit apache2.service entered failed state. ted@gremlin:~/SSLwork> I see something about the logs being inaccessable and also something about port 443 being unavailable. I have to check, but suspect that the log question may be due to a typo, but the question of the port is more concerning as there ought not be anything using 443 when apache is not running. How do I find out why apache can't bind to port 443? Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 8

[opensuse] segfault at 21, error 6 in libpthread-2.17.so
by Jeroen Groenewegen van der Weyden 31 Jul '14

31 Jul '14

Hi, On my opensuse 12.3 box I get these messages, segfault at 21, error 6 in libpthread-2.17.so glibc is at version 2.17 as provided by the online updates. anybody any idea how to fix this? kernel: 3.7.10-1.36-xen HW: IBM System x3550 M4 Server -[7914E7G] SW: OpenSUSE 12.3 ( all online updates are applied) **** /var/log/messages ************* 2014-07-30T15:50:35.891177+02:00 cln1 kernel: [ 4280.611256] monitor[20714]: segfault at 21 ip 00007f19d6c310a7 sp 00007fffd0285118 error 6 in libpthread-2.17.so[7f19d6c25000+17000] 2014-07-30T15:50:43.233783+02:00 cln1 cib: [3986]: info: cib_stats: Processed 258 operations (620.00us average, 0% utilization) in the last 10min 2014-07-30T15:51:51.525694+02:00 cln1 kernel: [ 4356.244605] monitor[20748]: segfault at 21 ip 00007f2e478400a7 sp 00007fff99d35de8 error 6 in libpthread-2.17.so[7f2e47834000+17000] 2014-07-30T15:53:07.172308+02:00 cln1 kernel: [ 4431.891129] monitor[20782]: segfault at 21 ip 00007f53de8d20a7 sp 00007fff803904e8 error 6 in libpthread-2.17.so[7f53de8c6000+17000] 2014-07-30T15:54:22.874816+02:00 cln1 kernel: [ 4507.593641] monitor[20816]: segfault at 21 ip 00007fa6943400a7 sp 00007fff60d92a68 error 6 in libpthread-2.17.so[7fa694334000+17000] 2014-07-30T15:55:38.550494+02:00 cln1 kernel: [ 4583.268457] monitor[20850]: segfault at 21 ip 00007f4d7e2170a7 sp 00007fff65957ed8 -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] Apache 2.4.6 on OpenSuse 13.1: ssl_error_rx_record_too_long and ERR_SSL_PROTOCOL_ERROR
by Ted Byers 30 Jul '14

30 Jul '14

This is killing me. After googling for days, and going down countless blind alleys, I am no closer to a solution. Much of the info I get is either ancient or for other platforms, or both. Worse, 99% of the pages I get blame the browser, but the browser is not relevant (except I get ssl_error_rx_record_too_long from Firefox and ERR_SSL_PROTOCOL_ERROR from Chrome: both on a workstations running OpenSuse 13.1). I know the browser is not to blame because the same browsers CAN connect to another of my servers (running Ubuntu 12.04) over https. I made sure that 443 is open in the firewall, and that the server is listening on 443, and that the virtual host using 443 is properly configured (or so I believe), with the proper filename and full path to the server's key and certificate, as well as to my rootCA certificate. The web server DOES start, and handles http requests perfectly. But every attempt to use SSL results in one of the above errors on the client side. On the server side, the only error I get relates to the web server not being able to find socache_shmcb_module; or so it says. In point of fact, the .so file is in /usr/lib64/apache2. I can not imagine why it would claim that it isn't installed (and that it would ignore that error), when in fact the file is there and the proper path to it has been provided in the LoadModule statement in the relevant conf file. As the only reference to variables related to this module occur in the virtual host that is supposed to be using SSL, I wonder if this error is causing the other two. I would include my *.conf files, but there are so many, and I am no longer sure of which files would be most useful, or which I should focus on (I have stared at all of them for so long, it is hard to read my screen), I'll post only those you ask for. I don't want to post anything that is not relevant. Please help. It is getting desperate here. I now have a headache that would kill an ox. It feels like my head is going to explode. If you see a mushroom cloud over central Ontario, Canada, you'll know what happened. :-( Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2

Re: [opensuse] Apache 2.4.6 on OpenSuse 13.1: ssl_error_rx_record_too_long and ERR_SSL_PROTOCOL_ERROR
by Ted Byers 30 Jul '14

30 Jul '14

On Tue, Jul 29, 2014 at 4:03 PM, Cristian Rodríguez <crrodriguez(a)opensuse.org> wrote: > El 29/07/14 a las #4, Ted Byers escribió: >> On Tue, Jul 29, 2014 at 3:36 PM, Cristian Rodríguez >> <crrodriguez(a)opensuse.org> wrote: >> > El 29/07/14 a las #4, Ted Byers escribió: >> >> This is killing me. After googling for days, and going down countless >> >> blind alleys, I am no closer to a solution. Much of the info I get is >> >> either ancient or for other platforms, or both. Worse, 99% of the >> >> pages I get blame the browser, but the browser is not relevant (except >> >> I get ssl_error_rx_record_too_long from Firefox and >> >> ERR_SSL_PROTOCOL_ERROR from Chrome: both on a workstations running >> >> OpenSuse 13.1). I know the browser is not to blame because the same >> >> browsers CAN connect to another of my servers (running Ubuntu 12.04) >> >> over https. >> >> >> >> I made sure that 443 is open in the firewall, and that the server is >> >> listening on 443, and that the virtual host using 443 is properly >> >> configured (or so I believe), with the proper filename and full path >> >> to the server's key and certificate, as well as to my rootCA >> >> certificate. >> >> >> >> The web server DOES start, and handles http requests perfectly. But >> >> every attempt to use SSL results in one of the above errors on the >> >> client side. >> >> >> >> On the server side, the only error I get relates to the web server not >> >> being able to find socache_shmcb_module; or so it says. In point of >> >> fact, the .so file is in /usr/lib64/apache2. I can not imagine why it >> >> would claim that it isn't installed (and that it would ignore that >> >> error), when in fact the file is there and the proper path to it has >> >> been provided in the LoadModule statement in the relevant conf file. >> >> As the only reference to variables related to this module occur in the >> >> virtual host that is supposed to be using SSL, I wonder if this error >> >> is causing the other two. >> >> >> >> I would include my *.conf files, but there are so many, and I am no >> >> longer sure of which files would be most useful, or which I should >> >> focus on (I have stared at all of them for so long, it is hard to read >> >> my screen), I'll post only those you ask for. I don't want to post >> >> anything that is not relevant. >> >> >> >> Please help. It is getting desperate here. I now have a headache >> >> that would kill an ox. It feels like my head is going to explode. If >> >> you see a mushroom cloud over central Ontario, Canada, you'll know >> >> what happened. :-( >> > Ted, run a test on the qualsys ssl tester.. https://www.ssllabs.com/ssltest/ >> > Share the result and tell us what the apache error log says, anything else is useless to debug the problem. >> >> Alas, that is a problem as that tester works only on public websites, >> with a proper domain name. In my case, the server in questions is >> private (no access to the web). Is there an alternative that I can >> run either on the server, or on one of the other machines on my LAN? >> >> > > Share the apache error_log , that will help most likely. > > > -- > Cristian > "I don't know the key to success, but the key to failure is trying to please everybody." OK. The whole error log is large, but here are the contents from the last couple days related to this: error_log: [Mon Jul 28 16:10:20.352233 2014] [mpm_prefork:notice] [pid 1385] AH00170: caught SIGWINCH, shutting down gracefully [Mon Jul 28 16:10:20.613620 2014] [ssl:warn] [pid 28770] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Mon Jul 28 16:10:20.624669 2014] [mpm_prefork:notice] [pid 28770] AH00163: Apache/2.4.6 (Linux/SUSE) OpenSSL/1.0.1h PHP/5.4.20 configured -- resuming normal operations [Mon Jul 28 16:10:20.624751 2014] [core:notice] [pid 28770] AH00094: Command line: '/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -D FOREGROUND' [Mon Jul 28 23:46:23.755117 2014] [mpm_prefork:notice] [pid 28770] AH00170: caught SIGWINCH, shutting down gracefully [Mon Jul 28 23:46:24.053688 2014] [ssl:warn] [pid 31870] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Mon Jul 28 23:46:24.065106 2014] [mpm_prefork:notice] [pid 31870] AH00163: Apache/2.4.6 (Linux/SUSE) OpenSSL/1.0.1h PHP/5.4.20 configured -- resuming normal operations [Mon Jul 28 23:46:24.065183 2014] [core:notice] [pid 31870] AH00094: Command line: '/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -D FOREGROUND' [Mon Jul 28 23:51:48.563226 2014] [mpm_prefork:notice] [pid 31870] AH00170: caught SIGWINCH, shutting down gracefully [Mon Jul 28 23:51:48.861576 2014] [ssl:warn] [pid 31990] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Mon Jul 28 23:51:48.871671 2014] [mpm_prefork:notice] [pid 31990] AH00163: Apache/2.4.6 (Linux/SUSE) OpenSSL/1.0.1h PHP/5.4.20 configured -- resuming normal operations [Mon Jul 28 23:51:48.871747 2014] [core:notice] [pid 31990] AH00094: Command line: '/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -D FOREGROUND' [Tue Jul 29 11:13:58.252916 2014] [mpm_prefork:notice] [pid 31990] AH00170: caught SIGWINCH, shutting down gracefully [Tue Jul 29 11:13:58.623591 2014] [ssl:warn] [pid 3643] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Tue Jul 29 11:13:58.636579 2014] [mpm_prefork:notice] [pid 3643] AH00163: Apache/2.4.6 (Linux/SUSE) OpenSSL/1.0.1h PHP/5.4.20 configured -- resuming normal operations [Tue Jul 29 11:13:58.636669 2014] [core:notice] [pid 3643] AH00094: Command line: '/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -D FOREGROUND' [Tue Jul 29 11:17:27.198447 2014] [mpm_prefork:notice] [pid 3643] AH00170: caught SIGWINCH, shutting down gracefully [Tue Jul 29 11:17:27.441729 2014] [ssl:warn] [pid 3844] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Tue Jul 29 11:17:27.451583 2014] [mpm_prefork:notice] [pid 3844] AH00163: Apache/2.4.6 (Linux/SUSE) OpenSSL/1.0.1h PHP/5.4.20 configured -- resuming normal operations [Tue Jul 29 11:17:27.451672 2014] [core:notice] [pid 3844] AH00094: Command line: '/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -D FOREGROUND' [Tue Jul 29 13:53:10.509851 2014] [mpm_prefork:notice] [pid 3844] AH00170: caught SIGWINCH, shutting down gracefully [Tue Jul 29 13:53:10.861175 2014] [ssl:warn] [pid 4874] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Tue Jul 29 13:53:10.874415 2014] [mpm_prefork:notice] [pid 4874] AH00163: Apache/2.4.6 (Linux/SUSE) OpenSSL/1.0.1h PHP/5.4.20 configured -- resuming normal operations [Tue Jul 29 13:53:10.874513 2014] [core:notice] [pid 4874] AH00094: Command line: '/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -D FOREGROUND' Most of the above is due to restarting after making changes suggested by the various pages I found taking about one aspect or another of this problem. And, as the virtual host affected is gremlin.site, here is the contents of gremlin's error log: [Mon Jul 28 16:23:15.902503 2014] [cgi:error] [pid 28788] [client 192.168.2.77:39731] attempt to invoke directory as script: /srv/www/vhosts/gremlin.site/cgi-bin/, referer: http://gremlin.site/ There is obviously nothing related to my SSL problem in the gremlin error log, but I include it as it is very short and it would be logical to ask what is in it. Here are the contents of my hosts file: # # hosts This file describes a number of hostname-to-address # mappings for the TCP/IP subsystem. It is mostly # used at boot time, when no name servers are running. # On small systems, this file can be used instead of a # "named" name server. # Syntax: # # IP-Address Full-Qualified-Hostname Short-Hostname # 127.0.0.1 localhost # special IPv6 addresses ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts 192.168.2.8 linux-5gh8.site linux-5gh8 127.0.0.2 gremlin.site gremlin I see a possible deficiency here, in that I suppose I ought to change the FQDN and short name to gremlin (I'll make that change and report back if it makes a difference). Finally, here are the contents of vhosts-ssl.conf: # Template for a VirtualHost with SSL # Note: to use the template, rename it to /etc/apache2/vhost.d/yourvhost.conf. # Files must have the .conf suffix to be loaded. # # See /usr/share/doc/packages/apache2/README.QUICKSTART for further hints # about virtual hosts. # NameVirtualHost statements should be added to /etc/apache2/listen.conf. # # This is the Apache server configuration file providing SSL support. # It contains the configuration directives to instruct the server how to # serve pages over an https connection. For detailing information about these # directives see http://httpd.apache.org/docs/2.2/mod/mod_ssl.html # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # <IfDefine SSL> <IfDefine !NOSSL> ## ## SSL Virtual Host Context ## <VirtualHost _default_:443 127.0.0.2:443 127.0.0.1:443 192.168.2.8:443 > ServerAdmin r.ted.byers(a)gmail.com ServerName gremlin.site DocumentRoot /srv/www/vhosts/gremlin.site # General setup for the virtual host #DocumentRoot "/srv/www/htdocs" #ServerName www.example.com:443 #ServerAdmin webmaster(a)example.com # ErrorLog /var/log/apache2/error_log # TransferLog /var/log/apache2/access_log ErrorLog /var/log/apache2/gremlin.site-error_log CustomLog /var/log/apache2/gremlin.site-access_log combined # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # SSL protocols # Supporting TLS only is adequate nowadays SSLProtocol all -SSLv2 # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 SSLVerifyClient optional SSLVerifyDepth 10 SSLOptions +ExportCertData +StdEnvVars # Speed-optimized SSL Cipher configuration: # If speed is your main concern (on busy HTTPS servers e.g.), # you might want to force clients to specific, performance # optimized ciphers. In this case, prepend those ciphers # to the SSLCipherSuite list, and enable SSLHonorCipherOrder. # Caveat: by giving precedence to RC4-SHA and AES128-SHA # (as in the example below), most connections will no longer # have perfect forward secrecy - if the server's key is # compromised, captures of past or future traffic must be # considered compromised, too. #SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5 #SSLHonorCipherOrder on # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. Keep # in mind that if you have both an RSA and a DSA certificate you # can configure both in parallel (to also allow the use of DSA # ciphers, etc.) --- default had 'server' where I have 'gremlin.site' SSLCertificateFile /etc/apache2/ssl.crt/gremlin.site.crt #SSLCertificateFile /etc/apache2/ssl.crt/server-dsa.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /etc/apache2/ssl.key/gremlin.site.key #SSLCertificateKeyFile /etc/apache2/ssl.key/server-dsa.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/apache2/ssl.crt/ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. SSLCACertificatePath /etc/apache2/ssl.crt #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt SSLCACertificateFile /etc/apache2/ssl.crt/rootCA.pem # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/apache2/ssl.crl #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details. #<Location /> #SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ #</Location> # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o StrictRequire: # This denies access when "SSLRequireSSL" or "SSLRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi|shtml|phtml|php|pl)$"> SSLOptions +StdEnvVars </FilesMatch> ScriptAlias /cgi-bin/ "/srv/www/vhosts/gremlin.site/cgi-bin/" <Directory "/srv/www/vhosts/gremlin.site/cgi-bin"> # <Directory "/srv/www/cgi-bin"> AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all SSLOptions +ExportCertData +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. BrowserMatch "MSIE [2-5]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # Per-Server Logging: # The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis. CustomLog /var/log/apache2/ssl_request_log ssl_combined </VirtualHost> </IfDefine> </IfDefine> Does any of this help determine what is awry? I can affirm that the paths and file names of the certificates and the server's key are correct and that the expects files are where they should be. Thanks for your time. Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 5

[opensuse] Available versions of LibreOffice
by Vojtěch Zeisek 30 Jul '14

30 Jul '14

Hi, this time appears from time to time... So... When I look at http://software.opensuse.org/package/libreoffice I'd expect to see LO 4.2 in LibreOffice:Stable as it is stable (well, 4.3 was released recently and https://www.libreoffice.org/download/libreoffice-fresh/ already offers it). What is the purpose of LibreOffice:4.2 repo? I'd expect to keep just LibreOffice:Factory for next openSUSE release, LibreOffice:Stable (with 4.2 and very soon with 4.3) for stable upstream and LibreOffice:Unstable for developmental upstream. But the last one contains only 4.1.1.2. It seems to me confusing and outdated. I'd rather use good oS repos as in case with KDE than RPMs downloaded from the web... Could anyone knowledgeable, please, explain and/or fix it? Thanks, Vojtěch -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/

1 0

[opensuse] replacing qpopper with dovecot
by Damon Register 30 Jul '14

30 Jul '14

I have just installed SuSE 13.1 and I wanted to install qpopper since that is what I was using to make local sendmail available to Thunderbird (pop3). I found that qpopper was missing from the repository and with a little google work, I found one post that asked about qpopper for 13.1. One person suggested using dovecot so I thought I would give it a try. Installing was easy and I thought running might be too. I started the service through yast, services manager. It seemed that dovecot didn't stay running so as suggested in dovecot manual, I looked at /var/log/mail. I saw that it failed on detection of the mail folder for my username. The manual had some info about that and suggested editing the dovecot.conf file. I did and now dovecot seems to be working and I can even connect from Thunderbird. It appears however that I might not understand very well how to get my goal for dovecot. I see that dovecot works and Thunderbird connects but I see that dovecot has created its own set of mail files and folders in the mail dir that seem to be parallel to the sendmail files but not connected with the sendmail files. Can anyone tell me how to get dovecot to do what I used to do with qpopper? I want dovecot to repackage sendmail messages for use by Thunderbird (or any other pop3 client). Damon Register -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

8 65

[opensuse] 13.1 - what is the interface you use for NetworkManager??
by David C. Rankin 29 Jul '14

29 Jul '14

All, I have always used traditional ifup, but with 13.1 I went with NetworkManager. No complaints. But, how the heck to you talk to it?? I've read man NetworkManager and found my wifi connection in /etc/NetworkManager/dispatcher.d, but now I need to switch wifi access points (the WAN port on my original router died) How do I tell NetworkManager to do this? Complicating the issue - both access points are running. I am still connected to the old (which the wifi works on -- just not the WAN port). I've added a default static route in 13.1 pointing to the new wifi router to get internet back, but now I need to tell Network Manger to drop it's connection to essid 'skyline' and establish a new connection to essid 'skyline_633' and then use 'skyline_633' as the new default. Do I do this from the command line, or is there some gui widget I should install? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2