welcome: please sign in

Upload page content

You can upload content for the page named below. If you change the page name, you can also upload content for another page. If the page name is empty, we derive the page name from the file name.

File to load page content from
Page name
Comment
Last name of the current Debian Project Leader

Revision 65 as of 2015-03-20 19:21:51

Edit

ClintonEbadi

I am Clinton Ebadi. I am the reluctant PresidentTreasurer of the coop (someone has to do it), and the current lead sysadmin / DomTool maintainer / lo-fi AdamChlipala replacement.

1. Board Statements

See /BoardStatements

2. General Coop Goals

Unstructured musing on when/what I think the coop ought to be.

3. Contact

4. Websites

5. Immediate Tasks

6. Admin Stuff

6.1. fastcgi setup notes

Notes to self about configuring fastcgi for at least php

http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

6.1.1. Packaging

6.1.2. Problems with openafs

The mod_fcgid spawner runs in its own process pool and therefore without tokens or the ability to acquire tokens for processes it launches. Thus, all fcgi processes must be wrapped to avoid surprising behavior. The FcgidWrapper directive is not very expressive: the "wrapper" is the fastcgi application that is launched and then passed any files matching the extension using SCRIPT_NAME. A wrapper wrapping script is needed to grab tokens before launching the actual wrapper, and just using {Add,Set}Handler fcgid-script won't work as expected (users could of course arrange for programs run that way to grab tokens manually).

mod_wsgid and mod_cgid have identical problems. Inspecting the apache source code makes it appear that it would be possible to fix the situation generally by adding a pre/post suexec hook. The process managers for mod_cgid/mod_fcgid/mod_wsgid are forked from the primordial apache process which I understand has all modules loaded. Modules like mod_auth_kerb and mod_waklog could then inject tickets/tokens/etc. into the environment from which external processes were spawned using the suexec hooks.

6.1.3. Setup Plans

6.2. Improve SSL Experience

6.2.1. Portal

The portal page should allow Intermediate CA Cert permission and installation requests. Installed CA certs should be presented as a drop-down showing the subject CN and file name.

The portal request page should display all certs and cacerts a user is permitted to use already, their common name, and their expiration date.

6.2.2. Managing Certificates

Upon installation, certificates should be recorded in a database that stores (filename, type, subject, expiration) (where type = user | intermediate). Removal, naturally, should remove the database entry and files from all web servers.

This information could then be used to present information on a member's certs on the portal page, and make requesting CA certs easier.

6.3. etc.

6.4. Website

(create Website bugzilla product and move these there)

6.4.1. Wiki

6.5. domtool plans

6.5.1. restricted modules for apache

Inspiration: hcoop.net's vhost is non generated by domtool, and only because it enabled mod_userdir

Idea: have a set of restricted modules that can only be used by superusers. Easiest to just have another ad-hoc list setting in config for domtool. ACL example: hcoop priv www, www priv overloaded to also allow use of restricted module.

Problems: no way currently to restrict access to actions or lib files.

Deficiences: priv www is a blunt instrument. priv system in general is mediocre. It might be nice to be able to do something like hcoop priv www apache-module/userdir mail/hopper.hcoop.net (i.e. access to all www nodes, access to the userdir module only, access to hopper). Keys gain some hierarchy polluting the purity of the triples db, but it is already a bit polluted... is there any difference between adding hierarchy to priv keys and the existing implicit hierarchies in domains and paths?

Solution: might be overkill just for mod_userdir, if it looks like minimal additional code is required perhaps implement hierarchical privs (extending www and mail privs to support limiting to particular admin hosts) and restricted apache modules.

What I'll probably do: just copy the vhost from deleuze onto navajos and call it a day for the next year or two.

6.5.2. Pattern Matching and New Types

A vague idea that may prove to be unworkable. I think at least implementing list matching in domtool would be quite useful. Abstraction syntax would be need to be improved to support multiple clauses. case would also be needed to make it useful. Syntax would be easy enough to add except for having to deal with runtime non-exhaustive match exceptions (perhaps requiring exhaustive matches and living with the limitation). Ambitious, probably time consuming, might require adding tail call optimization to the interpreter. Example:

(* A map operator *)
val map = \action -> \list -> 
  case list of head::tail =>
    begin
      action head;
      map action tail;
    end
     | [] => Skip;
(* Alias a list of email addresses to *)
val multiAlias = \sources -> \target -> map (\source -> emailAlias source target) sources;

I probably lack the skill/willpower in the short term... alternative idea, just implement a loop primitive in SML and magic the types away by making it a primitive construct (defining its type on DomTool/LanguageReference). Maybe implement polymorphic actions if adding then is secretly easy:

extern val map : (('a -> 'b) -> ['a]) -> [^Root];

(* Alias a list of email addresses to *)
val multiAlias = \sources -> \target -> map (\source -> emailAlias source target) sources;

Most of the gain, none of the pain.

New types: even more ambitious. Supporting at least tuples or named records, and perhaps a construct for querying the domtool acl database. Idea would be to use it for something like the firewall, where only primitive "generate one firewall rule" constructs would be needed, and then user firewalls could be constructed by querying the ports available to each user and matching/looping.

One pattern that has recurred in domtool is that of a special purpose client + server commands that operates on a simple database. E.g. spamassassin prefs, vmail users, firewall rules, and the domtool acl database. It would be useful to have a generalized serialize/unserialize sets of sml records library, perhaps with a generalized/queryable tuples database built on top of the primitive raw-records database. Even better would be to allow databases to be exposed to domtool, and simple queries performed on them. Maybe.

val writeRecord' : [('record -> 

6.6. Major Sysadmin Tasks for 2014

7. Board Stuff

8. etc

Barely formed sentences.

8.1. tt-rss at hcoop

Our postgresql does not use passwords. The installer needs a single tweak to remove the required attribute of the database password to install.

8.2. kallithea

Following https://pythonhosted.org/Kallithea/installation.html

cache_dir = %(here)s/data
index_dir = %(here)s/data/index
archive_cache_dir = %(here)s/tarballcache


CategoryHomepage