XS Community Edition/0.3/Configuring

Initial Setup

1. Use "ifconfig" to determine the ip address of the XS.
   Take note of its eth0-ip-address = WAN-ip.
   If you've inserted the USB Ethernet Adapter above (serving the LAN/Intranet) also take note of the school server's eth1-ip-address = LAN-ip = 172.18.96.1
2. If you inserted the USB Ethernet Adapter above, configure its own Wifi Access Point (AP) to properly serve other LAN/Intranet client XOs. (If the Wifi AP is a router, DO NOT plug into its "WAN" port -- instead use any of its LAN/normal ports. And be sure to enable the AP's "bridge mode" or similar, or specifically disable the AP's own DHCP)

Access Point Setup

It's best to start with your AP set to factory settings. You can search the model number to find reset instructions for your particular AP, as well as the IP of the administrative interface and the login credentials.

Once you've connected to the AP and logged into the administrative interface, turn off wifi security. You can always reenable it once you've made sure it's working with the XSCE.

Next, disable NAT and the DHCP server. Last, set the IP address of the AP to an IP in the 172.18.126.0/24 range and the netmask to 255.255.224.0. That IP range is set aside on the XSCE for static network devices. Be sure to make a note of what you set the IP to so you can get to it later when it's connected to the XSCE.

At this point, most APs require a reboot for the changes to go into effect.

Once you've got it connected to the XSCE and passing traffic, you can change the administrative password and enable wifi security if desired.

Web server (apache)

If you want to have simple password authentication to a web directory, it's fairly simple. Here's an example.

Say you'd like http://schoolserver/secret to be password protected. Create /etc/httpd/conf.d/secret.conf:

<Directory /var/www/html/secret>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride AuthConfig
  AuthName "This is a secret dir, but the user/password is secret/phoebe"
  AuthType Basic
  AuthUserFile /home/admin/.htpasswd
  Require user secret
</Directory>

Generate the password hash (these aren't the usual instructions because of a bug in Apache 2.4.4):

htpasswd -nb secret phoebe > /home/admin/.htpasswd

Where secret is the user name (no, it's not a user on the XSCE) and phoebe is the password.

Restart the server:

systemctl restart httpd.service

Now when users go to http://schoolserver/secret, they'll have to enter the username and password in a login box.

Proxy server and web cache (squid)

To disable squid: (eg. on an XO-1 whose memory/storage can only handle minimal services)

systemctl stop squid.service
systemctl disable squid.service
rm /etc/sysconfig/xs_httpcache_on
xs-setup-network

Virtual Private Network (open vpn)

Once you have the three files you need from your OpenVPN server admin, OpenVPN client setup on the XSCE is surprisingly simple.

The OpenVPN server admin needs to generate a client specific .crt and .key file for each user. In this example, my OpenVPN server admin generated anna.crt and anna.key for me. I also need the OpenVPN server's ca.crt file, which is the same for all clients. I put those files in /etc/openvpn.

Put the config file into /etc/openvpn:

cp /usr/share/doc/openvpn-2.3.1/sample/sample-config-files/client.conf /etc/openvpn

Now I have four files total in /etc/openvpn.

ls /etc/openvpn
anna.crt anna.key ca.crt client.conf

Just for the sake of example, we're going to pretend that laptop.org is running an OpenVPN server. Make the following change to client.conf for the OpenVPN server name:

From:
remote my-server-1 1194

To:
remote laptop.org 1194

Tell the config file what the client key files your OpenVPN server admin generated for you are named:

From:
cert client.crt
key client.key

To:
cert anna.crt
key anna.key

If your admin has named ca.crt to something other than that, edit that line in the config file for the filename.

Start the service:

systemctl start openvpn@client.service

To see if it worked, you can do ifconfig and see if the tun device exists and reports traffic. Note that all the traffic on the XSCE and its clients will now be passing through the OpenVPN tunnel. The external IP for the XSCE's network will be the OpenVPN server's external IP.

Content Filtering with OpenDNS

There are two components to settting up content filtering with OpenDNS. First, the XSCE needs to look at OpenDNS's DNS IP addresses for DNS. Then there must be an OpenDNS account associated with the XSCE's public IP address. Simply specifying the OpenDNS servers as the XSCE's DNS servers doesn't filter any content. You need to set up an account and configure the content filter level so that OpenDNS knows what to block for your specific IP address.

You may wish to use the OpenDNS DNS servers instead of your ISPs DNS servers if your ISP's DNS servers are unreliable. If you don't need content filtering, no account is required.

To point the XSCE to the OpenDNS DNS servers, edit /etc/named-xs.conf.in for the forwarders line:

options
{
        /* make named use port 53 for the source of all queries, to allow
         * firewalls to block all ports except 53:
         */
        forwarders {208.67.222.222; 208.67.220.220;};

Run this command to write the change to named-xs.conf.in to named-xs.conf:
xs-domain-config

Restart the named service:
systemctl restart named.service

Now the XSCE is pointing to OpenDNS's DNS servers. However, internet content will not be filtered until you set up an account with OpenDNS and configure your filter level.

From the IP you wish to enable content filtering for, go to http://www.opendns.com and create an account. When setting a label (friendly name) for your network, it's best to avoid special characters and spaces.

Once your OpenDNS account is created and your network is listed in the settings tab, click on the network's IP to manage settings. Under "Web Content Filtering," select your desired content filter level and click Apply.

If you have a static IP, setup is complete. If your IP is dynamic, the ddclient service is necessary to update OpenDNS when your IP changes.

The ddclient service requires three pieces of information about your OpenDNS account: username, password, and network label. The network label can be found under the OpenDNS Dashboard, in the settings tab, listed in the "LABEL" column under "Your networks."

To install ddclient:
yum -y install ddclient

At the bottom of /etc/ddclient.conf, append the following lines:

##
## OpenDNS.com account-configuration
##
use=web, web=myip.dnsomatic.com
ssl=yes
server=updates.opendns.com
protocol=dyndns2
login=yourlogin
password=yourpassword
your-network-name

Remember how you needed three pieces of information about your OpenDNS account? Edit these three lines with your OpenDNS login credentials and your OpenDNS network label:

login=yourlogin
password=yourpassword
your-network-name

Enable the ddclient service, for all future boots:
systemctl enable ddclient.service

Start the ddclient service, during the current boot:
systemctl start ddclient.service

If ddclient fails to start with the above command, reboot the XSCE and verify that ddclient came up at boot:
systemctl status ddclient.service

The default ddclient update interval is 300 seconds, which you can change in /etc/ddclient.conf.

Manually saving yum cache for repeat installations

Currently we're testing keeping the yum cache on a USB drive so subsequent installations go faster, but if you're having issues with getting that to work, there's a manual option. The XSCE installation process tells /etc/yum.conf to keep the yum cache, rather than the default XO behavior of discarding it. After a successful installation, you can pack up the yum cache to tote to another installation:

cd /var/cache/yum
tar cf xsce.tar *

Copy the tarball off. Unpack it on an XO with the same architecture and Fedora version.

tar xvf xsce.tar -C /var/cache/yum