Monday, October 09, 2017

6.1 amd64: Python 3 - ebaysdk UnicodeDecodeError.


Currently I'm testing Odoo 11, which now have moved from Python 2.7 support to Python > 3.5. For OpenBSD 6.1, the Python is already 3.6 so it should be of no issue.

However, this one particular package is currently uninstallable.


I tried using pip but I got errors. Take note the "requiremens.txt" only have ebaysdk in it.

$ doas pip install -r requirements.txt
The directory '/home/karl/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that
directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/home/karl/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directo
ry. If executing pip with sudo, you may want sudo's -H flag.
Collecting ebaysdk==2.1.4 (from -r requirements.txt (line 1))
  Downloading ebaysdk-2.1.4.tar.gz (40kB)
    100% |################################| 51kB 148kB/s
    Complete output from command python egg_info:
    Traceback (most recent call last):
      File "", line 1, in
      File "/tmp/pip-build-dvars6pw/ebaysdk/", line 26, in
        open(VERSIONFILE, "rt").read(), re.M).group(1)
      File "/usr/local/lib/python3.6/encodings/", line 26, in decode
        return codecs.ascii_decode(input, self.errors)[0]
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 29: ordinal not in range(128)

Command "python egg_info" failed with error code 1 in /tmp/pip-build-dvars6pw/ebaysdk/

All the other dependencies can be installed correctly except for this one. I try setting up the LC_CTYPE, LC_ALL, even LANG and LANGUAGE to en_US.UTF-8 but still unsuccessful.

I'm checking for workaround on this. Later.

Thursday, October 05, 2017

6.1 DL160 Gen9: Bought myself a domain, now to configure Nginx + acme-client.


Except the fact that the server's Smart Array Battery failing, my ProLiant DL160 Gen9 is doing great. I've long changed to running ESXi 6.0 and now it's VMware ESXi 6.5. Last time I wrote that I'm using XenServer but it's just a brief encounter. Having to install additional program for a web management feature is one of the negative point for me. So that's why I went back to VMware ESXi. Been learning a lot from this machine so I'm very excited and grateful.

What else is new? Ah. Got a very crazy deal for a domain registration which is buy 2 years and get 2 more years free for RM160! So I went for it and bought meself a domain. I should've bought more but I have no more budget. And before that I registered for a bargain 10Mbps Unifi plan for RM129/mth. Oh yeah and I moved to a new place.

As now I have my internet line at home, I can properly play around with the server and OpenBSD. My plan is to bring up my Odoo web online and *finally* start my small business.

So far, I have 2 OpenBSD vm. 1 vm is basically serving the local DNS (in progress), web (using Nginx), PostgreSQL, Fossil SCM and the other vm is doing nothing important (yet). In details: (also known as
- Unbound (not done).
- Nginx (serving Odoo through reverse proxy, Fossil SCM through SCGI, proxy pass to ESXi all in HTTPS).
- PostgreSQL.
- acme-client for SSL Certs (This particular post).

I learned acme-client quite a hard way. I configured the acme-client related files (/etc/acme-client.conf & /etc/nginx/nginx.conf) but every time I run the "acme-client -vAD" I received errors:

# acme-client: bad exit: netproc(xxxx): 1

Thinking that I can do trial/error as much as I wanted, I kept reconfiguring the files until I reached the limit of registration tries. Is it then that I read about it at Then I read about the "Staging" function (acme-client --staging) which I tried but not in the installed version in OpenBSD. I checked the /etc/acme-client.conf and found the staging block. So I altered it as:

===== /etc/acme-client.conf =====
#authority letsencrypt {
#    *snipped

#authority letsencrypt-staging {
authority letsencrypt {
    agreement url "bla bla
    bla bla bla
    account key "bla bla
===== /etc/acme-client.conf =====

Basically I commented the production block and "authority letsencrypt-staging" line. Using the same "acme-client -vAD" now will basically use the Staging URL instead of the production one so the limit is much higher which is useful for testing/debugging. I wish I knew this earlier. Because of the production limit, now I have to wait for a full 7 days before I can try and register again. Ah well, I can do more testing in the mean time.

After much re-configuration / testing cycle, I found that this configuration managed to successfully register my domain. Here's the additional block in /etc/acme-client.conf:

===== /etc/acme-client.conf =====
* snipped

domain {
    alternative names { }
    domain key "/etc/ssl/private/"
    domain certificate "/etc/ssl/"
    domain full chain certificate "/etc/ssl/"
    sign with letsencrypt
    challengedir "/var/www/acme/.well-known/acme-challenge"
===== /etc/acme-client.conf =====

And to compliment the above configuration, here's the /etc/nginx/nginx.conf configuration.

===== /etc/nginx/nginx.conf =====
# Default server
server {
    listen 80;

    location ^~ /.well-known/acme-challenge {
        default_type "text/plain";
        root /var/www/acme;

    location / {
        return 307$request_uri;

# ESXi
server {
    listen 80;
    server_name esx.mydomain,my;

    location ^~ /.well-known/acme-challenge {
        default_type "text/plain";
        root /var/www/acme;

    location / {
        return 307 https://$host$request_uri;

server {
    listen 443;
    ssl on;
    ssl_certificate    /etc/ssl/;
    ssl_certificate_key    /etc/ssl/private/;

===== /etc/nginx/nginx.conf =====

Do take note that the "default_type "text/plain";" line is optional. I tried registering without it and it's fine. The "ESX" block is also not completed yet as virtual console have "Failed to connect" error which is for another post. After reconfiguration then I restarted Nginx then run acme-client again.

# rcctl restart nginx
# acme-client -vAD
* snipped
acme-client: /etc/ssl/ created
acme-client: /etc/ssl// created

Noted the the double-slash "//" on the fullchain.pem. Although it seems like something not working, I can still find the fullchain.pem file in /etc/ssl folder. And when I checked the SSL Certificate, the issuer > Common Name (CN) is stated as "Fake LE Intermediate X1" which is as what Let's Encrypt documented.

So far I've done a few test and it's ok. I need to wait until this Sunday (or next Monday) before I can try and register again. Later.