Tag Archives: status

Posted on
by

A big piece of functionality that people have been asking for in Known (and that I actually needed to start building out for some client work), was the ability to add a “draft” published status on a post, which was separate from “PRIVATE” in an ACL context.

To start building this out I introduced the concept of publish_status (defaulting to “published”) on an Entity. Originally I implemented this as a piece of metadata, however since this had issues with filtering queries by “NOT ‘draft'” owing to this bug, I’m proposing a new pull request which implements the same functionality as a collection level schema change.

This obviously requires some DB patches to be applied, but it is both more efficient and more flexible.

Posted on
by

So, I’ve been using Known to post to post status updates for a little while now, the latest of which you can see in the sidebar on the right hand side (which is displayed using a WordPress plugin I wrote).

Known also lets you reply to messages directly from your site (replying to other sites that enable webmentions, twitter, or even Github), but unfortunately, while Known has a configurable timeline (so you can choose what content to display by default) the standard Known status message plugin doesn’t differentiate between posts and replies.

Because it was bugging me having my timeline filled with reply messages to various places (which were out of context for most people) I wrote a patch for the Status plugin that will allow you to differentiate between messages and replies in both the content type selector and the homepage configuration tool.

My timeline now shows everything by default, except replies (you can still see those if you select “All Content” from the selector), and this is also reflected in my sidebar!

I’ve submitted this as a pull request upstream which has yet to be merged, but in the mean time you’ll need to apply the patch from my development fork.

Posted on
by

The server-status page gives you a wealth of information about your apache server, and among other things it is necessary for the Apache munin plugin to work. However, by default it exposes sensitive data when run behind a squid reverse proxy.

In order to lock this down, you need to modify your /etc/squid/squid.conf file slightly…

acl no_stats urlpath_regex /server-status
http_access deny no_stats

This defines an ACL that will prevent squid from giving access to any request ending in /server-status. Because, in a reverse proxy configuration, it is squid that is hit when a client request a page from port 80, this prevents public access.

You’re not quite done though, because this setting assumes that your real web server (sitting behind the squid proxy on a different port) is NOT publicly visible. This can be achieved by placing it behind the firewall.

Munin

If you’re using munin to monitor your apache processes, you’ll need to make a small modification to the /etc/munin/plugin-conf.d/munin-node file, add/modify the following:

[apache_*]
env.url http://127.0.0.1:%d/server-status?auto
env.ports [apache server port]

This will tell the apache plugins where the server status page is, and what port the real apache instance is running on.