All sysop issues
From eg
This list is a subset of all issues - mirror this list there.
Contents |
[edit] sysop issues: high priority
See: todo and we/will/must policy/goal items from meetings, i.e. statements that include or imply what "we will" do, what "we must" do to get there, etc., from sysop meeting 2005-12-12 log.
Please, all users are sysops, THIS LIST IS YOURS TO UPDATE, do not leave it up to the trolls, they will surely make a mess of it all:
This list is just a copy of all sysop issues - update it there, not here.
[edit] eg:defer list
Who we are and who we defer to on what issue needs to be settled - well before sysop meeting 2006-03-15.
[edit] Ides of March
Everything fails on that day and the sysop meeting 2006-03-15 is just to verify that - the page Ides of March contains a list of predicted failures expected on that day so that we can elaborate the list of services and deferral relationships to prevent those.
Even if the project disappears that day there will probably have been something learned. At the very least, an archive of this wiki should be preserved in tomb-like form. This will aid future archaeologists of consensus to figure out why our society failed.
[edit] dom0
issue: running any services on dom0 may open up security holes and destroy trust.
- position: hypervisor should boot the virtual hosts and then sleep. run mail/dns/wiki on individual VMs.
- position: it's a tradeoff in complexity of managing, the sysops.be SSdomU is already slated to do a lot, but its failure modes may not be that graceful without some things done by sysops.be dom0.
- position: dedicated hosts work best, they are reliable and easy to clone from known configurations, even if there is lots of redundancy in the service configuration
[edit] lvm: isn't that scary?
- position: lvm experimenting speeds over file backed storage slightly, but enables backup without "creating inconsistencies as things change in the filesystem": "You can do 'lvm' snapshots of a partition for backups, which means creating a static image of the partition in question which can then be used as a backup" without this conecern
- argument against: "probably less portable, meaning that you cant copy a file between machines and have it appear as a virtual machine on the new host machine easily."
- argument for: after you snapshot an lvm filesystem, you can mount it, and copy it to a file: when you're done with your copy you just gun the snapshot, very convenient
- argument for: the snapshot uses some clever tricks so that its only a fraction of the size of a real partition, use copy-on-write so that the snapshot partition only reverse deltas to maintain its state, very quick and fast
- argument for: if lvm is installed, we should be able to non-destructively resize the current partition scheme and add partitions for our own virtual machines: If you do 'mount' it says /dev/mapper/vg00-root on / type ext3, indicative ( /dev/mapper ) of lvm
- argument against: none of us know anything about this: boxen with "massive partitions that could be cleared for experimenting" can/should be hacked only by someone there on site who bothers to learn lvm
[edit] Root Policy: update timing
- position "non-security updates should be applied manually - they tend to be bigger and more likely to break things, and they're less urgent usually" - near-agenda by farm_boy, sysop meeting 2005-12-12
- position: only larger updates by some criteria should be manual, there are trivial patches that are "non-security"
- argument for: since Debian separates security updates from updates that add or remove features, is there not some other way to identify features that haven't been used since the install? Some logging feature? if so then it's also possible to identify other updates that don't have to be manual
- position: even the security updates are rarely that urgent, to wait and batch them all at regular intervals during scheduled downtime is the best policy
- argument against: When security updates are urgent they are very urgent indeed. For example, if the system is vulnerable to an internet worm and one is live, then waiting for scheduled downtime may leave an unacceptably long period in which the system is likely to become infected. Cleaning up after such an infection usually involves unscheduled downtime which is inconvenient for users and a real drain on sysop resources. Security issues should be evaluated according to a combination of the likelihood of an incident and the cost of an incident. Even if urgent security updates are rare, the cost of cleaning up after even one bad incident is greater than the cost of applying all security updates as they become available.
- argument against: It's easy and unobtrusive. Debian separates security updates from updates that add or remove features. Security updates from debian can almost always be applied without breaking anything.
[edit] please find more issues
There are more issues, see sysop meeting 2005-12-12 log and add them above with the positions taken, and reasonable alternative ones.
The Ides of March will definitely force attention to all sysop issues one way or another.
