Installing and operating Xibo on Fedora 17

tl;dr

  • server  => “easy as WordPress”
  • client => you’re on your own with GPU-level source code assembly.

Who: Xibo

Server

  • The server install is pretty walk-through easy
  • You install and build on-site from source (a copied php tree).
  • As such there are SELinux issues because there are no appropriate labels
    • but there is a semanage fcontext pattern set herein.

Robustness

  • The server install workflow self-checks for errors.
  • It rechecks the self-checks to ensure that changes didn’t occur with the install flow.
  • It conveniently restarts the install flow again if it didn’t work.

Client

  • Requires lots of work; Ubuntu 10.04 is the “no work” path
    • The “source code” distributes with a prebuilt libbrowsernode.so
    • Only available/tested on 32-bit OSes (Ubuntu 10.04 32-bit)
  • Has a python installer
    • sudo bash .../xibo-1.4.0-ubuntu.all-pyclient.sh
  • Has low-level hardware compatibility issues
  • libbrowsernode is barely supported

Architecture

Clients are (stationary, static) venues connect to the server which contains the media schedule and the media library.  Venues are only defined in this dynamic sense by the act of a client connection. Once a client connects, it can operate in a sporadic offline mode.  If there are no clients connecting, yet or ever, there are no venues.  Thus there is no way to prepopulate the definition and schedule for a media campaign.  Venues are expected to be fullscreen (i.e. this isn’t an in-browser type ad server).

Server (Admin UI and Media Database)

  • LAMP

Client (Venue Player)

  • Bespoke with direct GPU rendering
    • i.e. not Firefox in Kiosk mode
    • i.e. not mplayer
    • i.e. not anything else easy.
    • There are no other client options besides direct GPU hacking
  • Components
  • libbrowsernode Build Instructions

Cultural Fit

The Xibo system seems tuned for Unixalike-on-Windows with a .NET base and Python plus XAMPP being a suggested variant stack; and thence backported into Ubuntu with a straight-up LAMP stack as  a secondary option. Subtly this means that Fedora should work but there will be “issues.” There is some wording that there are Windows-specific and Ubuntu-specific components that are necessary for the client player.

Details

See the pages on Xibo

The SELinux booleans and Apache httpd

 References

Just about the booleans, not about the labels…

Actualities

$ getsebool -a | grep httpd
allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_connect_ftp --> off
httpd_can_connect_ldap --> off
httpd_can_connect_zabbix --> off
httpd_can_network_connect --> on
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_graceful_shutdown --> off
httpd_manage_ipa --> off
httpd_read_user_content --> off
httpd_run_stickshift --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_tmp_exec --> off
httpd_tty_comm --> on
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_fusefs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
httpd_verify_dns --> off
$ uname -a
Linux opened 3.6.6-1.fc16.i686.PAE #1 SMP Mon Nov 5 17:11:25 UTC 2012 i686 i686 i386 GNU/Linux
$ cat /etc/fedora-release 
Fedora release 16 (Verne)
$ rpm -q -a | grep -Ee '(policy|http)' | sort
checkpolicy-2.1.6-2.fc16.i686
httpd-2.2.22-2.fc16.i686
httpd-tools-2.2.22-2.fc16.i686
policycoreutils-2.1.4-13.fc16.i686
policycoreutils-gui-2.1.4-13.fc16.i686
policycoreutils-python-2.1.4-13.fc16.i686
policycoreutils-restorecond-2.1.4-13.fc16.i686
policycoreutils-sandbox-2.1.4-13.fc16.i686
polkit-desktop-policy-0.102-3.fc16.noarch
python-httplib2-0.7.4-6.fc16.noarch
selinux-policy-3.10.0-96.fc16.noarch
selinux-policy-targeted-3.10.0-96.fc16.noarch

Bring up multiple WordPress instances on Fedora 16

Problem Statement

  • WordPress, circa WordPress 3.4.2
  • Fedora 16
    • SELinux to be used
    • Dual-stack visibility (IPv4 and IPv6)3
  • Multitenancy => multiple nonstandard locations for the code, config & data management trees.
    • Multiple blog sites
    • Multiple web sites

Design

  • /etc/httpd virtual hosting
  • /var/http contains multiple web sites at /var/http/sitename
  • /var/wordpress contains multiple blog sites at /var/wordpress/blogname
  • /etc/wordpress contains the multiple wp-config.php, each named sitename.php
    Therefore the symlink /var/wordpress/sitename/wp-config.php has the (pointer) value ../../../etc/wordpress/sitename.php

Expectations

Expect policy-version and release dependencies surrounding the SELinux in the new location. Fedora 16 isn’t the latest thing out there, so some of the policy problems will already have been fixed. Other policy problems will appear do the new use case: installing in an unexpected location.

Concept: SELinux is good, and true and wonderful, and it will protect you. Use it, learn it, live it. The pain you feel is operations safety entering your system.

Rewrite

Redirect

Previous Experiences

cd /var/wordpress/landfill
sudo chcon -v -R --reference=/var/www/html .
sudo semanage fcontext -a -t httpd_sys_rw_content_t
/var/wordpress/landfill/wp-content/uploads
sudo restorecon -v /var/wordpress/landfill/wp-content/uploads
getsebool -a
sudo setsebool -P httpd_can_network_connect on

Outstanding Issues

  1. Uploading a new header; error message: Image could not be processed. Please go back and try again.
    • nothing in /var/www/httpd/landfill/error_log
    • nothing in /var/log/messages/

    Suggestion: yum install php-gd
    Reference: cite
    Result: not helpful (no change)

    Dec 1 00:07:28 opened yum[13986]: Installed: t1lib-5.1.2-9.fc16.i686
    Dec 1 00:07:28 opened yum[13986]: Installed: php-gd-5.3.18-1.fc16.i686

References