Warnings

There’s no warranties the drivers will work, for you!

If you are satisfied with the open-source radeon drivers, don’t risk to break your computer !

Still there will NEVER be a fglrx driver for recent kernel and xorg. So if one of those component change in Leap fglrx will be broken.

Actual situation

Since last december, AMD doesn’t published any update about fglrx so the version is still the 15.12.302 published. A few days ago our beloved Leap release manager Ludwig ask me by email, if there will be an available drivers for Leap 42.2.

Today, after hacking a bit the last Sebastian Siebert’s script I’ve been able to build the drivers for Leap 42.2 RC1, and the driver install fine, and xorg start on my HD5750 (but that’s all what I can tell).

I will rebuild the driver once Leap 42.2 will hit its final stage.

Repository

zypper ar -cfg -n FGLRX http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_Leap_42.2/ FLGRX

zypper -v refresh -f FGLRX

zypper -v install fglrx64_amdcccle_SUSE422 fglrx64_core_SUSE422 fglrx64_graphics_SUSE422  fglrx64_opencl_SUSE422 fglrx64_xpic_SUSE422

Future

AMD has stopped any development for FGLRX, so it is already considered obsolete. But on the other side they make a lot of effort to bring radeon and amdgpu (the free and open source driver) to a decent performance level.

I don’t have that much usage anymore of my AMD gpu powered computer, and my HD5750 is now 8 years old already, so I can’t promise to be able to follow up with changes.

Cleanup

I removed all the obsoletes packages letting only the last one for each openSUSE version still available. Also the server has no more copy of openSUSE github artwork. If this missing to someone, don’t hesitate to ask.

Have fun

I still get questions from time to time about how to deploy a python web application using Apache and not NGINX. Here is a quick tutorial to deploy your Flask application on Ubuntu 16.04 or any linux distribution (considering relevant changes) using Apache, Gunicorn and systemd. Until some weeks ago I used supervisord instead of systemd but nowadays I prefer to use systemd because is already there, installed, part of system. And also the reason to look into systemd and to switch was that I had to deploy an application on SLES (SUSE Linux Enterprise Server) and there is no supervisord package available in repos.

Note: This is a very basic configuration to get everything running. It is just for learning and to get the idea how everything is connected.

So, let's start:

• we create a user which will run our Flask application

# adduser flaskappuser

• install and configure apache:

# apt-get install apache2

As result we should get the default apache webpage in browser (http://your-ip-here)

• we have to enable proxy modules for apache:

# a2enmod

and give this list of modules to enable:

proxy proxy_ajp proxy_http rewrite deflate headers proxy_balancer proxy_connect proxy_html

• Add our application to apache web server config file. Add the following lines (inside VirtualHost block) to /etc/apache2/sites-available/000-default.conf. Make a backup of this file before you modify it

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPreserveHost On
    <Location "/flaskapp">
          ProxyPass "http://127.0.0.1:5000/"
          ProxyPassReverse "http://127.0.0.1:5000/"
    </Location>

so, the final file should look like this:

<VirtualHost *:80>
    # The ServerName directive sets the request scheme, hostname and port that
    # the server uses to identify itself. This is used when creating
    # redirection URLs. In the context of virtual hosts, the ServerName
    # specifies what hostname must appear in the request's Host: header to
    # match this virtual host. For the default virtual host (this file) this
    # value is not decisive as it is used as a last resort host regardless.
    # However, you must set it for any further virtual host explicitly.
    #ServerName www.example.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf
    <Proxy *>
        Order deny,allow
          Allow from all
    </Proxy>
    ProxyPreserveHost On
    <Location "/flaskapp">
          ProxyPass "http://127.0.0.1:5000/"
          ProxyPassReverse "http://127.0.0.1:5000/"
    </Location>
</VirtualHost>

• restart apache to see if is working:

# service apache2 restart

http://your-ip-here —> should give you the same standard html page for apache, as before

http://your-ip-here/flaskapp —> should give you:

Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

that’s because we still don’t have our Flask app running, but it seems that apache is trying to send the request to it, good.

• let’s take care of our Flask app:

we will run it in a virtual environment, so let’s install virtualenv:

# apt-get install python3-venv

create and activate our new venv:

# cd /home/flaskappuser
# mkdir flaskapp
# cd flaskapp
# python3.5 -m venv flaskvenv
# source flaskvenv/bin/activate

install flask and gunicorn in our venv:

# pip install flask gunicorn

create out simple flask app (/home/flaskappuser/flaskapp/app.py)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/usr/bin/env python

from flask import Flask

app = Flask(__name__)

@app.route("/")
def index():
    return "Hello from FLASK"

if __name__ == "__main__":
    app.run(host='127.0.0.1')

let’s run our app to see if is working:

(flaskvenv) root@apache-flask:~/flaskapp/# python app.py
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
127.0.0.1 - - [10/Oct/2016 13:58:56] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [10/Oct/2016 13:58:59] "GET / HTTP/1.1" 200 -

in your web browser you should see: Hello from FLASK if you try: http://your-ip-here/flaskapp

• everything is ok right now, but we want to use Gunicorn as our application server, so let’s configure it

in the same place where your Flask application is (/home/flaskappuser/flaskapp/ in my case) create a gunicorn.conf file with the following content:

accesslog = "/home/flaskappuser/flaskapp/logs/gunicorn_access.log"
errorlog = "/home/flaskappuser/flaskapp/logs/gunicorn_error.log"

we have to create our directory where to store the logs files:

# mkdir logs

now we can try to test our app again by running it using gunicorn:

# gunicorn -c gunicorn.conf -b 0.0.0.0:5000 app:app

check the browser and see if you app is working. Should work 😃

make sure that everything in flaskappuser home directory belongs to this user

# chown -R flaskappuser:flaskappuser /home/flaskappuser/

Now we have one more step. We want to monitor our Flask app and to restart it on crashing or to have nice start/stop commands for it. Or to have it started automatically on reboot. In order to do that we can use systemd which is available already in Ubuntu 16.04.

For that we have to create a .service file for our app. Here is my file: (/etc/systemd/system/flaskapp.service):

[Unit]
Description=flaskapp
After=network.target

[Service]
User=flaskappuser
Restart=on-failure
WorkingDirectory=/home/flaskappuser/flaskapp/
ExecStart=/home/flaskappuser/flaskapp/flaskvenv/bin/gunicorn -c /home/flaskappuser/flaskapp/gunicorn.conf -b 0.0.0.0:5000 app:app

[Install]
WantedBy=multi-user.target

activate our .service file

# systemctl daemon-reload

enable it at boot/restart

# systemctl enable flaskapp

start our app

# systemctl start flaskapp

Check if our app is running:

(flaskvenv) root@apache-flask:~/flaskapp# tail -f /var/log/syslog
Oct 10 14:25:59 guest systemd[1]: Started ACPI event daemon.
Oct 10 14:26:03 guest systemd[1]: Started flaskapp.

(flaskvenv) root@apache-flask:~/flaskapp# ps aux | grep gunicorn
flaskappuser      7263  0.2  2.9  64904 22492 ?        Ss   14:26   0:00 /home/flaskappuser/flaskapp/flaskvenv/bin/python3.5 /home/flaskappuser/flaskapp/flaskvenv/bin/gunicorn -c /home/flaskappuser/flaskapp/gunicorn.conf -b 0.0.0.0:5000 app:app

check the app in your browser:

http://your-ip-here/flaskapp

you can stop your app with:

# systemctl stop flaskapp

Done!

Note: Here is my repository with the files: GitHub

Even though we just had the nice and successful ownCloud Contributor Conference there have quite some ownCloud releases happened recently. I like to draw your attention to this for a moment, because some people seem to fail to see how active the ownCloud community actually is at the moment.

There has been the big enterprise release 9.1 on September 20th, but that of course came along with community releases which are in the focus here.

We had server release 8.0.15, server release 8.1.10, server release 8.2.8 and release 9.0.5. There are maintenance releases for the older major versions, needed to fix bugs on installations that still run on these older versions. We deliver them following this plan.

The latest and greatest server release is release 9.1.1 that has all the hardening that also went into the enterprise releases.

Aside a ton of bugfixes that you find listed in the changelog there have also been interesting changes which drive innovation. To pick just one example: The data fingerprint property. It enables the clients to detect if the server got a backup restored, and saves changes on the clients to conflict files if needed. This is a nice example of solutions which are based on feedback from enterprise customers community running ownCloud, who help with reporting problems and proposing solutions.

Talking about professional usage of ownCloud: Of course also all the server release are available as linux packages for various distributions, for example the ownCloud server 9.1.1 packages. We think that our users should not be forced to deploy from tarballs, which is error prone and not native to Linux, but have the choice to use linux packages through the distributions package management.

There also have been client releases recently: The Android client versions 2.1.1 and 2.1.2 were released with important changes for Android 7 and much more fixes, as well as iOS client versions 3.5.0 and 3.5.1. The desktop client 2.2.4 also got a regular bug fix update (Changelog).

I guess you agree that is a lot of activity shown in the ownCloud project, making sure to get the best ownCloud experience out there for the users, driven by passion for the project and professional usage in focus.

If you are interested and want to join in and make ownCloud better, jump in on ownCloud Central or Github. It’s fun!