1. Domtool
Everyone's favorite spiffy system for letting legions of users manage the same daemons securely.
AdamChlipala says:
- I would like to rewrite this completely, for reasons including: From a software engineering perspective, the implementation is not so nice. There is no support for configuring multiple machines from the same configuration file source. Scalability with the increasing amount of configuration is not so hot. The current configuration scheme encourages copying-and-pasting, which makes it hard to make sweeping changes to our suggested configuration base.
JustinLeitgeb says:
- If we're doing this, let's think about storing configuration information in a database. It seems that it should scale better, and it would certainly be easier to write programs for users to configure domains via a web interface. I'm also thinking about writing a tool to set up a host with a dynamic IP on the internet (like what dyndns.org provides). For this to occur, we basically need to factor in the ability for fairly frequent, small changes to DNS zones without completely reloading the server. Also we need to be able to configure the TTL on host records (this may already be possible in domtool, I haven't checked). If the new domtool is written in Perl, I will be able to make software contributions, otherwise I probably won't have time to learn a new language in the next few years.
AdamChlipala says:
- My conception of the optimal configuration tool makes every configuration file a program, with textual structure that maps very poorly to a relational database, so I am still strongly against the idea of SQL-based configuration.
- domtool already supports everything needed for dynamic DNS, including setting TTL, as someone already requested support for doing that himself.
- I won't be involved with any Perl development.
JustinLeitgeb says:
- OK, I understand where you're coming from if you want the configuration files to be programs. I agree that it will be a stronger system that way.
1.1. References to how we do things now
2. Portal
2.1. Decisions that we've agreed on
- Keep doing the same as now, running on Main
2.2. References to how we do things now
3. Web e-mail client
3.1. Decisions that we've agreed on
Keep using SquirrelMail, running on Main
3.2. References to how we do things now
4. Webmin/Usermin
4.1. Decisions that we've agreed on
- Keep doing the same as now, running on Main
4.2. References to how we do things now
5. Wiki
5.1. Decisions that we've agreed on
- Start from the same data as our current wiki
- Host the wiki on Main
Keep using MoinMoin
5.2. Questions to be resolved
- Upgrade the wiki to the latest release, even if there is no Debian package for it.
MichaelOlson says:
I want to upgrade the Moin software to the latest release. The main reason for this is that the UserPreferences page is broken in the current version, in that it has no Mail me my account data button, in spite of the instructions on that page. This seems to be fixed on the official Moin wiki, so it is most likely fixed in the latest release.
- The idea is for me to start by upgrading my LUG's wiki instance. If no unsolvable problems are encountered, then upgrade HCoop's wiki instance as well. If no up-to-date Debian package is found (and there wasn't one, last time I checked), I could either:
(a) make a Debian package, using the Debian patches against their moin package as a reference, or
(b) backup the Debian additions (site-wide wiki farm settings), remove the moiin Debian package, and install it from source.