This page is for the administration of chicagolug.org. If you'd like to help, please join #chiglug-server on irc.oftc.net.

Contents

Software

Please track all changes you make to any software here:

Debian (Kevin)

Apache (Alex)

  • see /etc/apache2/include/www.chicagolug.org
  • user dirs are enabled.
  • use LDAP for any situations requiring HTTP authentication.
  • use mod_rewrite to require SSL for certain URLs.
  • WebDAV is enabled for SVN

Awstats (Ken)

  • generated from a script in /etc/cron.hourly
  • custom scuro.pm plugin adds the scuro theme

Cacti + snmpd (Ken)

Chump (John/Ken/Tristan)

  • chump runs on chicagolug.org now.
  • There have been a number of ChiGLUG improvements to the standard chump code, including the lettering output, and the search engine.
  • Note from Jess in IRC: encoding within the XML (John's end) needs to be changed to UTF-8

Dirvish (JQ)

  • We're getting emails about cron errors...

ipTables (JQ)

  • as a general rule, make sure each service is listening only on the interfaces it needs; for example, don't let mysqld listen on anything but the loopback adapter.
  • kdreyer installed fail2ban 08-23-2007 to cut down the SSH attacks
  • some IPs are blocked in /etc/hosts.deny

IRC Stats (Ken)

  • pisg uses my irssi log
  • the source is hacked in several places, particularly HTMLGenerator.pm, for the scuro theme.

LDAP (JQ)

  • registration now available
  • update function for passwords now available
  • Needs to be able to update password field
  • Someone please check this form for injection attacks
  • I think we could use a simple management tool for the admins. Possible features could be listing all users, list users by filter, option to delete users, etc.

Mailman (Alex)

  • This sorce is hacked in several places in order to accomodate the scuro skin.
    • mm_cfg.py
    • other .py files... I have tried to save copies of these with a .clug extension.
    • several /etc/mailman/en files

Mediawiki (JQ)

  • Custom skin
  • LDAP plugin - we should look into upgrading this extension.
  • CreateBox plugin
  • we are at version 1.9.3, we should look into upgrading to 1.11.0.

MySQL (Jess)

PHP5 (Alex)

SSH

  • only protocol 2 allowed

SUDO

(place user in wheel group in /etc/groups)

Planet (Kevin)

  • Generated from script in /etc/cron.hourly
  • To update the heads page, cd to the planet directory, then run ./update-heads

SVN (Ken)

Videos (Jordan)

Features

  • Website Skins
    • A note about centralizing things: This time around, we have just one scuro.css. It’s located at /assets/styles/scuro.css. When writing web apps, please link to this file instead of copying it.
  • LDAP
    • Tie all authentication methods into this.
  • Jquigley’s weekly backup – /etc /root /home /var/lib /var/www
    • Where are the MySQL databases stored?

Website TODO

  • On the mediawiki skin, "Discuss" link should be red if there's no "Discuss" page yet
  • Potential redesign of homepage
  • Move search box to the top navigation?
  • Scuro skin on websvn
  • change /wiki/includes/Parser.php to remove the regex https?:\/\/(www\.)?(chicago|chig)lug\.org from all external URLs.
  • We need to be tracking all changes to all software installed.

Website Homepage Redesign

Problem: Our website homepage has kind of evolved from our temporary placeholder page. We need to rethink the design of the homepage, as well as the central navigation.

Things to consider:

  • Usability
  • Accessibility
    • no need to go overboard here, but it must be navigable via the keyboard as well as the mouse
  • Content
    • What content do we want on the homepage?
      • News?
      • Meeting date/time/place/topics?
      • Can we integrate the articles section of the wiki?
      • Other ideas?
    • How do we keep time sensitive materials from expiring?
  • Navigation
    • I propose a mediawiki extension that could generate the navigation for us as follows. Tsaylor 13:05, 18 June 2007 (CDT)
      • There would be a page with all the main headings listed as links to either URLs or other wiki pages.
        • Links are just copied to the navigation bar and styled properly.
        • For wiki pages, the extension copies the links on that page to a subnav bar and places a link in the main nav bar that opens the subnav bar via JS. If the user doesn't use JS, it would fall back to just taking them to the wiki page.
      • This makes the navigation stupid easy for anyone to modify in the future.
      • It would have to cache the nav bar links in a post-processing state or this could be too processor intensive since it would run on every page hit.
      • Relevant links:
    • Tim I'm having trouble picturing this. Maybe you could explain more?--Kdreyer 01:02, 21 June 2007 (CDT)
  • hits on / must not be too processor- or memory-intensive, as this index page will always be hit substantially more often than anywhere else

Contact

  • Alex: arakoczy#arakoczy.com
  • Ken: ktdreyer#gmail.com
  • Kevin: special.kevin#gmail.com
  • Jess: jbalint#gmail.com
Powered by MediaWiki