Re: [opensuse] Apache 2.4.6 on OpenSuse 13.1: ssl_error_rx_record_too_long and ERR_SSL_PROTOCOL_ERROR
On Tue, Jul 29, 2014 at 4:03 PM, Cristian Rodríguez <crrodriguez@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@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@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@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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 29, 2014 at 4:53 PM, Ted Byers <r.ted.byers@gmail.com> wrote:
On Tue, Jul 29, 2014 at 4:03 PM, Cristian Rodríguez <crrodriguez@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@opensuse.org> wrote:
El 29/07/14 a las #4, Ted Byers escribió:
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).
Alas, making that change did not change the result. i still get the same errors. Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I have found a clue to at least one of my problems. I had written that:
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.
What I have observed is that, even though this module (socache_shmcb_module) is in the directory I indicated when I manually added the LoadModule statement to loadmodules.conf in /etc/apache2/sysconfig.d, during the process of starting apache2, apache2 does not find the module and thus removes the loadmodule statement in the loadmodules.conf file relating to socache_shmcb_module. What is the magic incantation required to have apache2 find this module when it is processing /etc/sysconfig/apache2, and before it touches loadmodules.conf? Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 29/07/14 a las #4, Ted Byers escribió:
What I have observed is that, even though this module (socache_shmcb_module) is in the directory I indicated when I manually added the LoadModule statement to loadmodules.conf in /etc/apache2/sysconfig.d, during the process of starting apache2, apache2 does not find the module and thus removes the loadmodule statement in the loadmodules.conf file relating to socache_shmcb_module. What is the magic incantation required to have apache2 find this module when it is processing /etc/sysconfig/apache2, and before it touches loadmodules.conf?
Do not do that.. use a2enmod socache_shmcb and restart apache..btw..this is kinda bug'ish.. it has been fixed in factory/13.2 however. Not a bug per se, as the sysadmin is supposed to read the documentation and know what modules are needed..but it confuses users. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 29, 2014 at 10:40 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 29/07/14 a las #4, Ted Byers escribió:
What I have observed is that, even though this module (socache_shmcb_module) is in the directory I indicated when I manually added the LoadModule statement to loadmodules.conf in /etc/apache2/sysconfig.d, during the process of starting apache2, apache2 does not find the module and thus removes the loadmodule statement in the loadmodules.conf file relating to socache_shmcb_module. What is the magic incantation required to have apache2 find this module when it is processing /etc/sysconfig/apache2, and before it touches loadmodules.conf?
Do not do that.. use a2enmod socache_shmcb and restart apache..btw..this is kinda bug'ish.. it has been fixed in factory/13.2 however.
Not a bug per se, as the sysadmin is supposed to read the documentation and know what modules are needed..but it confuses users.
Thanks Cristian. Now, having acted on what you said, the error message about socache_shmcb is gone. Further, we now know that this error had nothing to do with why SSL is not yet working. I might actually live long enough to get this thing running with out errors. ;-) Thanks again, Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Here is more disturbing info: ted@gremlin:~/SSLwork> sudo /usr/sbin/apache2ctl -S root's password: VirtualHost configuration: *:80 is a NameVirtualHost default server gremlin.site (/etc/apache2/vhosts.d/vhost.conf:15) port 80 namevhost gremlin.site (/etc/apache2/vhosts.d/vhost.conf:15) port 80 namevhost gremlin.site (/etc/apache2/vhosts.d/vhost.conf:15) port 80 namevhost gremlin.site (/etc/apache2/vhosts.d/vhost.conf:15) port 80 namevhost gremlin.site (/etc/apache2/vhosts.d/vhost.conf:15) ServerRoot: "/srv/www" Main DocumentRoot: "/srv/www/htdocs" Main ErrorLog: "/var/log/apache2/error_log" Mutex ssl-stapling: using_defaults Mutex ssl-cache: using_defaults Mutex default: dir="/run/" mechanism=default Mutex mpm-accept: using_defaults PidFile: "/run/httpd.pid" Define: DUMP_VHOSTS Define: DUMP_RUN_CFG User: name="wwwrun" id=30 Group: name="www" id=8 ted@gremlin:~/SSLwork> I wish I knew about apache2ctl earlier. but anyway, why is there nothing in this output about my SSL virtual host? Thanks Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Cristian Rodríguez -
Ted Byers