todo/doneikiwiki-hostinghttp://ikiwiki-hosting.branchable.com/todo/done/ikiwiki-hostingikiwiki2023-04-03T20:10:19Zvarious small changes from Debian packaginghttp://ikiwiki-hosting.branchable.com/todo/various_small_changes_from_Debian_packaging/2023-04-03T20:10:19Z2023-03-30T08:55:41Z
<ul>
<li><p>Use Testsuite: autopkgtest-pkg-perl</p>
<p> Recent versions of autodep8 will append our debian/tests/control to the
one they generate, so we no longer need to replicate what autodep8 would
have produced.</p></li>
<li><p>d/tests/pkg-perl/smoke-files: The makesite test needs an extra file copied</p>
<p> Fixes: 278d8ae4 "Fix the test suite to work when ikiwiki-hosting is not installed"</p></li>
<li><p>d/control: Depend on python3-docutils instead of python-docutils</p>
<p> This catches up with the corresponding change to ikiwiki's Suggests in
version 3.20180105-1.</p>
<p> Also explicitly depend on python3, again matching ikiwiki's Suggests.</p>
<p> Closes: <a href="https://bugs.debian.org/945656">#945656</a></p></li>
</ul>
<p><a href="http://ikiwiki-hosting.branchable.com/patch/">Branch</a>:
<a href="https://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/shortlog/refs/heads/deb-packaging">https://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/shortlog/refs/heads/deb-packaging</a></p>
<p>--<a href="http://ikiwiki-hosting.branchable.com/users/smcv/">smcv</a></p>
<blockquote><p><span class="selflink">merged</span> --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote>
strict transport securityhttp://ikiwiki-hosting.branchable.com/todo/strict_transport_security/2017-05-01T16:33:48Z2017-04-19T14:57:22Z
<p>I noticed a change in my local config during my last ikiwiki-hosting
upgrade: I had enabled <a href="https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security">HSTS</a> in my local apache template, to
prevent downgrade attacks in cases where HTTP to HTTPS redirection is
enabled.</p>
<p>The <a href="http://ikiwiki-hosting.branchable.com/patch/">patch</a> is trivial, and I encourage you to <a href="https://gitlab.com/anarcat/ikiwiki-hosting/commit/07d443ee33d366c68a57f3d6515ddfbc19147572">merge it</a> from
my <a href="https://gitlab.com/anarcat/ikiwiki-hosting/tree/hsts">hsts branch</a>. I used an arbitrary 6-month delay, but would
welcome comments on better policies... This was a key part in getting
my site a <a href="https://observatory.mozilla.org/analyze.html?host=anarc.at">better score</a> on the <a href="https://observatory.mozilla.org/">Mozilla SSL Observatory</a>. I made
other changes at the global level on the server configuration, but
this one is vhost-specific, so I had to roll it out in the Apache
template. With the changes, I was able to move from a D- score to A-.</p>
<p>Thanks! --<a href="http://ikiwiki-hosting.branchable.com/users/anarcat/">anarcat</a></p>
<blockquote><p><span class="selflink">merged</span> --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote>
some SSL improvementshttp://ikiwiki-hosting.branchable.com/todo/some_SSL_improvements/2014-04-15T19:48:10Z2014-04-15T10:56:16Z
<p>Please consider my <code>ready/ssl</code> <a href="http://ikiwiki-hosting.branchable.com/patch/">branch</a>:
<a href="http://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/shortlog/refs/heads/ready/ssl">http://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/shortlog/refs/heads/ready/ssl</a></p>
<p>Changes are:</p>
<ul>
<li><p>Include /etc/ikiwiki-hosting/b-foo/apache-ssl.conf.tmpl in the SSL
vhost, but not the unencrypted vhost. This is a good place to configure
HTTP basic/digest authentication or adjust SSL ciphers, for instance.</p></li>
<li><p>Similarly, for completeness, include
/etc/ikiwiki-hosting/b-foo/apache-source.conf.tmpl in the
source.foo vhost.</p></li>
<li><p>apache.conf.tmpl is included in all vhosts (unencrypted, SSL and source)
as before.</p></li>
<li><p>Give sites a boolean redirect_to_https option. If on, the normal port-80
vhost behaves like the aliases, redirecting to the SSL vhost.</p></li>
<li><p>If a SSL key exists, but redirect_to_https is not set, unencrypted aliases
redirect to the unencrypted main site (but SSL aliases redirect to the
SSL site).</p></li>
</ul>
<p>That last change makes it much more palatable to have a public,
mostly-read-only site that doesn't need SSL for normal use, but install a
self-signed or otherwise non-cartel-approved certificate so that a few
authorized editors (who can be taught to verify the self-signed cert by
fingerprint) can use password authentication securely. For instance,
that's probably what I'm going to do for my blog.</p>
<p>Truth table: suppose www.example.com is the canonical/preferred name of
example.com, aka example.branchable.com.</p>
<pre><code>redirect from |r_t_https=0 |r_t_https=1 | old behaviour
---------------+-------------+-------------+-------------
http://www.e.c |(no redirect)|https://www |(no redirect)
https://www.e.c|(no redirect)|(no redirect)|(no redirect)
http://e.c |http://www |https://www |https://www
https://e.c |https://www |https://www |https://www
http://e.b.c |http://www |https://www |https://www
https://e.b.c |https://www |https://www |https://www
</code></pre>
<p>--<a href="http://ikiwiki-hosting.branchable.com/users/smcv/">smcv</a></p>
<blockquote><p><span class="selflink">merged</span> --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote>
do not enable mod_userdir just so we can disable ithttp://ikiwiki-hosting.branchable.com/todo/do_not_enable_mod__95__userdir_just_so_we_can_disable_it/2014-04-19T19:26:11Z2014-04-14T20:21:45Z
<p>ikiwiki-hosting-web.postinst does <code>a2enmod userdir</code> so that it can use
<code>UserDir disabled</code>. This seems a little silly.</p>
<p>My <code>ready/userdir</code> <a href="http://ikiwiki-hosting.branchable.com/patch/">branch</a> fixes that.</p>
<p><a href="http://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/commitdiff/refs/heads/ready/userdir">http://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/commitdiff/refs/heads/ready/userdir</a></p>
<p>--<a href="http://ikiwiki-hosting.branchable.com/users/smcv/">smcv</a></p>
<blockquote><p>What about upgrades?</p>
<p>Anyway, I think that the idea here was to make the confuration work even
if used alongside an apache that did have userdir configured for other
sites. --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p>
<blockquote><p>Look at the patch, I think I already addressed both objections <img src="http://ikiwiki-hosting.branchable.com/smileys/smile.png" alt=":-)" /></p>
<p>There are two changes:</p>
<ul>
<li>don't force mod_userdir on in the postinst; upgrades unaffected.</li>
<li>wrap the <code>UserDir disabled</code> directive in <code><IfModule mod_userdir.c></code>,
so that if it's loaded, we disable it, but if it isn't, we do nothing.
Upgraded machines (and machines where the sysadmin wants userdirs on
another vhost) will load mod_userdir, but disable it for ikisite-managed
vhosts; new installations won't need to load it at all.</li>
</ul>
<p>--<a href="http://ikiwiki-hosting.branchable.com/users/smcv/">smcv</a></p>
<blockquote><p><span class="selflink">merged</span> --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote></blockquote></blockquote>
apache 2.4 supporthttp://ikiwiki-hosting.branchable.com/todo/apache_2.4_support/2014-04-19T19:26:11Z2014-04-14T02:56:06Z
<p>apache 2.4 has some changes in Debian which makes ikiwiki-hosting struggle. at the very least the filenames in <code>sites-available</code> need to change to have a <code>.conf</code> suffix, but there may be more I'm missing.</p>
<p>i have a (so far) working <a href="http://ikiwiki-hosting.branchable.com/patch/">patch</a> in my git repo (<code>git://src.anarc.at/ikiwiki-hosting</code>) branch <code>dev/apache24</code>. --<a href="http://ikiwiki-hosting.branchable.com/users/anarcat/">anarcat</a></p>
<blockquote><p>I think your patch is going to break Apache 2.2 users (like, er,
branchable.com) - I think it's OK to write out <code>$apache_site.conf</code>
unconditionally, but then you have to use <code>a2ensite $apache_site.conf</code>
for 2.2 or <code>a2ensite $apache_site</code> for 2.4.</p>
<p>It would also be nice to clean up the old files automatically.</p>
<p>Lower-priority, it would be nice to avoid the deprecated (and somewhat
confusing) Order, Allow and Deny directives for 2.4, which could be
achieved like so:</p>
<pre><code><IfVersion < 2.4>
Order allow,deny
allow from all
</IfVersion>
<IfVersion >= 2.4>
Require all granted
</IfVersion>
</code></pre>
<p>or by using the template engine.</p>
<p>I've opened an equivalent bug in Debian so it can be on the
Debian Apache packagers' radar. --<a href="http://ikiwiki-hosting.branchable.com/users/smcv/">smcv</a></p>
<p>Please consider my <code>ready/apache24</code> branch.
<a href="http://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/shortlog/refs/heads/ready/apache24">http://git.pseudorandom.co.uk/smcv/ikiwiki-hosting.git/shortlog/refs/heads/ready/apache24</a></p>
<p>It does not handle migration from ikisite-example.com to
ikisite-example.com.conf at the time you install Apache 2.4: that can be done
by disabling and re-enabling all sites, if Apache 2.4 doesn't get an
automatic migration in its maintainer scripts before jessie is released
(which seems to be the plan). However, it does work with both 2.2 and 2.4.
--<a href="http://ikiwiki-hosting.branchable.com/users/smcv/">smcv</a></p>
<blockquote><p>What if I have an apache 2.2 host that has lots of existing sites
configured with <code>$apache_site</code>? This patch seems to cause them to break
in some way or another until I disable/reenable them all.</p>
<blockquote><p>I might have misunderstood what you're getting at here: do you mean
"I have an Apache 2.2 host and switch it to smcv's patched
ikiwiki-hosting while keeping Apache 2.2", or "I have an Apache 2.2
host and switch it to Apache 2.4"?</p>
<p>The former worked for me... I'm still using Apache 2.2 on the server
that I'm interested in upgrading. Old sites remain in the old,
Apache-2.2-only scheme; when I disable and re-enable a site,
it's moved to the new scheme, which works either way.
If you've tried this and encountered a bug, or spotted a bug
via code review, please explain?</p>
<p>The latter is not (yet) expected to work, unless you disable and
re-enable all ikisites (which I wanted to avoid for now, because
I think some of mine still have local edits, although merging my
ssl branch hopefully removed the need for that). It looks as though
the Apache 2.4 maintainer scripts might do it, one day. It would
maybe be reasonable to add an "ikisite migrate" subcommand,
which either does the disable/enable for every site or does a
more minimal rename-the-configurations step, and make
ikiwiki-hosting-web's maintainer script run it - would you like me to
try that? --s</p></blockquote>
<p>Did you consider just making ikisite write out both <code>$apache_site</code> and
<code>apache_site.conf</code>? Then the runtime complication of needing to
<code>a2ensite $apache_site.conf</code> on 2.2 goes away. --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p>
<blockquote><p>Maybe. I was worried that when the Apache maintainers get round to this:</p>
<pre><code>#XXX: Deal with the sites-available/sites-enabled *.conf transition, e.g. rename
# all files which look like site configuration?
</code></pre>
<p>that process could get broken by having both ikisite-example.com and
ikisite-example.com.conf in sites-available. --s</p>
<blockquote><p>Ok, this seems acceptable and I'm ok with punting handling upgrades to
2.4 yet, in hopes apache will deal with it. <span class="selflink">merged</span> --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote></blockquote></blockquote></blockquote>
better error handlinghttp://ikiwiki-hosting.branchable.com/todo/better_error_handling/2014-04-14T02:51:42Z2013-09-07T23:59:52Z
<p>There are a few places where error handling can be improved in ikiwiki, i have a patch in my git repo to help with that.</p>
<p>See the master branch of <code>git://src.anarc.at/ikiwiki-hosting</code>, commit 271f36ad2abbbd37fd3997d9d7419f60cbbc4dc8.</p>
<p>This <a href="http://ikiwiki-hosting.branchable.com/patch/">patch</a> was <span class="selflink">merged</span> in 0.20140227. --<a href="http://ikiwiki-hosting.branchable.com/users/anarcat/">anarcat</a></p>
do not strip comments from ssh keyshttp://ikiwiki-hosting.branchable.com/todo/do_not_strip_comments_from_ssh_keys/2012-11-04T16:33:05Z2011-12-17T18:25:05Z
<p>It seems that comments are stripped from SSH keys when uploaded. This is unfortunate as it makes it harder to figure out which key is which. -- <a href="http://ikiwiki-hosting.branchable.com/users/anarcat/">anarcat</a></p>
<blockquote><p><span class="selflink">done</span> --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote>
anon git access by external domainhttp://ikiwiki-hosting.branchable.com/todo/anon_git_access_by_external_domain/2011-11-26T19:03:12Z2011-05-15T21:37:25Z
<p>Currently, git://externl.example.com/ doesn't work. For this to work,
ikisite needs to manage links in /var/lib/ikiwiki-hosting-web/git/ for
each configured external domain. --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p>
<blockquote><p><span class="selflink">done</span> .. note that the Branchable tab still shows the internal
domain in git urls. It's generally ok to use, unless you have some existing
domain that is moving to Branchable, etc. --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote>
directoryhttp://ikiwiki-hosting.branchable.com/todo/directory/2011-11-26T19:03:12Z2010-09-24T01:54:04Z
<p>Wanted: Directory of sites. Could be used for:</p>
<ul>
<li>internal monitoring of what sites are being made and used</li>
<li>possibly, a public directory (modulo privacy concerns)</li>
</ul>
<p>Data structure could be a directory with pages, created by ikisite when it
creates sites, by filling out a template. (And removed by ikisite when it
deletes sites.) Then the pages could be used to build a rss feed of sites,
or they could have aggregation directives, to make a planet of their
recentchanges feeds.</p>
<p>So, it needs to support multiple observing sites. At the simplest, it could
be configured thus:</p>
<pre><code># List of sites that will be updated when sites are added/removed.
# These sites should each have a template named observesite.tmpl, which
# will be filled out to create pages under sites/existing/ and
# sites/removed/
observersites="internal.branchable.com www.branchable.com"
</code></pre>
<p><code>ikisite observe hostname</code> can be called with either an existing, or a
non-existing hostname, and will update its pages for each of the observed
sites. It should only create the page for a hostname if it does not already
exist (to allow us to annotate hostnames with our comments, etc). When
removing a page, it should move it to removed/ (preserving its content).
It should also move any subpages associated with the site. That way we
can add comments, screenshots, etc.</p>
<hr />
<p>If we had a privacy flag, sites would need to be hidden if the flag
was set, and unhidden if it was cleared. Deferred for later. We'd
probably want to manually review sites in a public directory anyway,
and tag ones we want to publish.</p>
<p><span class="selflink">done</span></p>
cleanup unowned siteshttp://ikiwiki-hosting.branchable.com/todo/cleanup_unowned_sites/2011-11-26T19:03:12Z2010-08-18T20:07:19Z
<p>If a user starts to make a site, but never clicks the Finish button,
the site will be made in the background, and linger around.</p>
<p>Such sites can be detected because the admin is <code>http://none/</code>.</p>
<p>Something should handle cleaning these up. Especially since
the user may later try again with the same name.</p>
<p><span class="selflink">done</span> -- ikisite-delete-unfinished-site written, can be used in cron job</p>
anonymous git pushhttp://ikiwiki-hosting.branchable.com/todo/anonymous_git_push/2011-11-26T19:03:12Z2010-07-20T18:57:33Z
<p><span class="selflink">done</span>.. needs some testing though</p>
<p><a href="http://ikiwiki.info/tips/untrusted_git_push/">http://ikiwiki.info/tips/untrusted_git_push/</a></p>
<p>The main sticking point on this is that git-daemon runs as a single user,
who cannot write to all the sites. Seems some sort of suid wrapper is
called for.. Or is it?</p>
<p>How about this:</p>
<ul>
<li>Add a "ikiwiki-anon" user, with locked password etc. Run git-daemon
as that user. (done)</li>
<li>In branchable plugin, add a new "anonpush" config setting.
Should default to false, and be forced to false when branchable=0.
(done)</li>
<li>Set <code>untrusted_committers</code> to ikiwiki-anon on all sites by default.
(done)</li>
<li>Set <code>git_wrappermode: 6755</code> on all sites. (ikiwiki-anon will run the
wrapper when a commit is pushed; need to run it as the site user) (done)</li>
<li>Make ~/source.git and all its contents be writable be ikiwiki-anon.
Somehow. Note that normal unix permissions don't suffice. (done?)</li>
<li>When anonpush is enabled, enable <code>git_test_receive_wrapper</code> --
and when it's disabled, disable it, and delete the hook. (That
hook slows down all commits some.. a C wrapper that
just checks the uid of the committer would allow speeding it back up.)
(done)</li>
<li>When anonpush is enabled, <strong>after</strong> wrapper setup.
run: <code>git config daemon.receivepack = true</code>
(and undo when disabled). (done)</li>
<li>Set core.sharedRepository to true, in all bare repos. Needed to ensure
dirs in bare repo are always made writable by group.
(Already done, and spot checks indicate it's working; also tested
that it works when the sourcedir is temporarily 700 and a commit comes
in.)</li>
<li>Update do=branchable page to say when anonpush is enabled. (done)</li>
</ul>
<h2>permissions mess</h2>
<p>All the above is reasonable except the bit about permissions. Problem is
that both ikiwiki-anon and the site user need to be able to write to the
git repo. But it's not enough to make it 02775 siteuser:ikiwiki-anon, because
when ikiwiki-anon makes new directories like objects/xx/, it will own
them, and as the site user is not in the ikiwiki-anon group, it will not
be able to write to those subdirs, leading to later failure.
Similarly, when the site user makes commits, it will make directories owned
by it, that ikiwiki-anon cannot write to.</p>
<p>The site user cannot be in the ikiwiki-anon group, because then they could
access and write to other sites' repositories.</p>
<p>Pre-creating all possible object subdirectories and making them
02755 siteuser:ikiwiki-anon probalby won't work well; git-gc will
delete empty object subdirectories, and it would be easy to miss some
directory that git creates.</p>
<p>Use ACLs? Would require filesystem support (ie, that ext234 filesystems be
mounted with 'acl' option, which does not appear to be the default).</p>
<p>The magic settings seem to be:</p>
<pre><code>chmod g+s source.git # already done by git init --bare --shared
sudo setfacl -R -m d:g:ikiwiki-anon:rwX,d:g:$siteuser:rwX,g:ikiwiki-anon:rwX,g:$siteuser:rwX source.git
</code></pre>
<p>This allows ikiwiki-anon to read/write to all files/dirs in the repo,
and sets all directories to propigate the ACL to new files/dirs as they
are created. When ikiwiki-anon creates a file or directory, it will
be owned by ikiwiki-anon:siteuser, and siteuser can always write to it.</p>
git remotes configuratorhttp://ikiwiki-hosting.branchable.com/todo/git_remotes_configurator/2011-11-26T19:03:12Z2010-07-20T18:57:33Z
<p>A web interface for git remotes configuration would be very handy.</p>
<ul>
<li>Should make it really easy to set up pushing to github.</li>
<li>Should be possible to push a site to any other git repo too.</li>
<li>A special case is pushing changes to a site over to a branch of that
site.</li>
</ul>
<h2>design</h2>
<p><code>ikisite</code> already handles backup/restore of <code>.ssh/id_*</code>, so ssh-keygen
can be used a generate a passwordless ssh key for a site when remotes are
first set up. Provide a way to download the ssh public key, to provide to
github, etc.</p>
<p>For each remote, the user only needs to configure:</p>
<ul>
<li>The git URI, in any of the forms git recognises, <em>except</em> file:/// and
a bare path to a local repo.</li>
<li>Whether to make the remote a mirror. (<code>git push --mirror</code>; force-update
the remote refs)
Or find a sane default.</li>
<li>Possibly, the remote branch to push origin/master to. (Or a prefix, so
it pushes to foo/master, foo/setup, etc.)
Being able to push origin/master to github/branchable might be nice,
but this feature could be omitted for simplicity initially.</li>
</ul>
<p>The pushing should be run by a post-update hook. Currently, the post-update
hook is the ikiwiki wrapper. So, the pushing could be implemented by
an ikiwiki plugin. It could use the <code>refresh</code> hook, which will always be
called when a change is made or received.</p>
<p>The plugin should daemonize, drop locks, wait a short while to avoid
contending with the main site build, and then push to configured remotes.</p>
<h2>gotchas</h2>
<p>ssh host key checking needs to be dealt with somehow. By disabling
StrictHostKeyChecking in <code>~/.ssh/config</code>? Should be ok for
public/branchable repositories. The risk is that for a non-public
repository, an unsafe push could be done, exposing its contents.</p>
<p>ssh (or http) could stall asking for a password. The daemonization should
avoid this by ensuring that any controlling terminal is detached from.</p>
<p>May need to force push if pushing to an empty remote. (--mirror avoids
that problem)</p>
<blockquote><p>basic gitpush plugin now <span class="selflink">done</span> --<a href="http://ikiwiki-hosting.branchable.com/users/joey/">Joey</a></p></blockquote>
htaccess supporthttp://ikiwiki-hosting.branchable.com/todo/htaccess_support/2011-11-26T19:03:12Z2010-05-03T00:52:00Z
<p>.htaccess files are currently ignored. Would be nice to allow
users to include them in their source, and use them.</p>
<p>On the ikiwiki side, that is just a matter of configuring <code>includes</code>
to make it not skip .htaccess files.</p>
<p>On the apache side, config has to include 'AllowOverride All'. Also
'Options SymLinksIfOwnerMatch' is needed to use the RewriteEngine from
htaccess files.</p>
<p>Apache's <a href="http://httpd.apache.org/docs/1.3/howto/htaccess.html">htaccess documentation</a>
explains the overhead that searching for and using htaccess files entails.</p>
<p>We'd need to look at the security of it and make sure .htaccess files
cannot do anything bad.</p>
<p>A final reason not to do it, btw, is that it locks us into using apache.</p>
<p><span class="selflink">done</span> -- see <span class="createlink"><a href="http://ikiwiki-hosting.branchable.com/ikiwiki.cgi?do=create&from=todo%2Fhtaccess_support&page=design%2Fapacheinclude" rel="nofollow">?</a>apacheinclude</span>.</p>
external hostnameshttp://ikiwiki-hosting.branchable.com/todo/external_hostnames/2011-11-26T19:03:12Z2010-03-27T00:44:27Z
<p>Need to support domain names that the user has configured to CNAME to
the site hostname (or ugh, has hardcoded our IP).</p>
<p>Per the <a href="http://ikiwiki-hosting.branchable.com/design/">design</a>, each site has a primary url, which may be
an external domain or one we assign. It may also have any number of
aliases.</p>
<h2>ikiwiki configuration</h2>
<p>Set url, cgiurl to use the primary url. (do something about historyurl and
diffurl too, or will they point at a different domain?)</p>
<h2>apache configuration</h2>
<p>Serve requests in the primary domain.</p>
<p>For alias domains, hard redirect to the page in the primary domain?
The other option would be to also serve pages under the alias domains,
which would work, but since ikiwiki uses some absolute urls (ie, the cgiurl),
the user would tend to bounce over to the primary domain eventually anyway.</p>
<p>Probably it's better for caching, link visited status, and even
security, for only one domain to really be used.</p>
<h2>data storage</h2>
<p>(The primary url is best stored as the url field in ikiwiki's config.)</p>
<p>The list of aliases needs to be stored somewhere. This could be in a
separate <span class="createlink"><a href="http://ikiwiki-hosting.branchable.com/ikiwiki.cgi?do=create&from=todo%2Fexternal_hostnames&page=design%2Fdatabase" rel="nofollow">?</a>database</span>, or it could be in ikiwiki's own config.</p>
<p>If in ikiwiki's own config, it may or may not be editiable via websetup,
depending on whether we have granted a given user the ability to use
external domain names.</p>
<p>Currently, I am storing it using the ikiwikihosting plugin's urlalias setup file
setting.</p>
<p><span class="selflink">done</span> (mostly)</p>