Interesting test I saw this morning:
http://everythingsysadmin.com/the-test.html
I think we do pretty well overall, but there's some areas we could improve in.
kevin
On Mon, 2011-07-25 at 10:16 -0600, Kevin Fenzi wrote:
Interesting test I saw this morning:
http://everythingsysadmin.com/the-test.html
I think we do pretty well overall, but there's some areas we could improve in.
You're right, we don't do terribly on that list at all.
We've gotten much better at remote processes and global changes.
Some of our SoP's need to be updated but in general they are documented.
I've thought a bit about the SoPs and I've been wondering - do we want to move them OUT of the wiki and onto infra.fp.o?
I ask specifically b/c if our stuff goes sideways - recovering infra.fp.o is a priority but we may not know HOW to without being able to get to the wiki webserver, let alone the db.
Just a thought... -sv
On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
I've thought a bit about the SoPs and I've been wondering - do we want to move them OUT of the wiki and onto infra.fp.o?
Or have a cron job that exports them from the wiki and into static pages on infra.fp.o, instead of moving them?
On Mon, 2011-07-25 at 12:31 -0400, Ian Weller wrote:
On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
I've thought a bit about the SoPs and I've been wondering - do we want to move them OUT of the wiki and onto infra.fp.o?
Or have a cron job that exports them from the wiki and into static pages on infra.fp.o, instead of moving them?
It still means editing them on the wiki which, imo, is onerous and overkill for what they are. That might just be me, though, but I suspect it isn't. Wiki editing is slow and cumbersome, I've found and a brief interview with a few others in sysadmin-* bears out my suspicion..
Here's what I was thinking, actually:
infra-docs git repo on /git on infra.fp.o
docs exported on commit/push to infra.fp.o/infradocs/ or some such dir
maybe in markdown or rst - but probably just plain text to start with.
The folks who are most likely to write an SoP are going to be comfy with a text editor, I suspect.
It means if someone goes through and mauls the wiki we don't end up with broken docs in our DR location on infra.fp.o.
It also gives us an opportunity to sift through all of our docs in the transition and dump out the ones that don't matter anymore or just aren't accurate.
It would be simple to redirect all SoPs over to that site so no one gets lost.
In general I like the idea of infra.fp.o being the one place we need to recover to bring everything else back up and to know how to bring everything back up.
-sv
On Mon, Jul 25, 2011 at 12:43:28PM -0400, seth vidal wrote:
On Mon, 2011-07-25 at 12:31 -0400, Ian Weller wrote:
On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
I've thought a bit about the SoPs and I've been wondering - do we want to move them OUT of the wiki and onto infra.fp.o?
Or have a cron job that exports them from the wiki and into static pages on infra.fp.o, instead of moving them?
It still means editing them on the wiki which, imo, is onerous and overkill for what they are. That might just be me, though, but I suspect it isn't. Wiki editing is slow and cumbersome, I've found and a brief interview with a few others in sysadmin-* bears out my suspicion..
Here's what I was thinking, actually:
infra-docs git repo on /git on infra.fp.o
docs exported on commit/push to infra.fp.o/infradocs/ or some such dir
maybe in markdown or rst - but probably just plain text to start with.
The folks who are most likely to write an SoP are going to be comfy with a text editor, I suspect.
It means if someone goes through and mauls the wiki we don't end up with broken docs in our DR location on infra.fp.o.
It also gives us an opportunity to sift through all of our docs in the transition and dump out the ones that don't matter anymore or just aren't accurate.
It would be simple to redirect all SoPs over to that site so no one gets lost.
In general I like the idea of infra.fp.o being the one place we need to recover to bring everything else back up and to know how to bring everything back up.
I think the biggest benefits of the wiki are a table of contents (Where on the ISOP:PKGDB page do I find something about removing a package?) and hyperlinks. (I'm making a new release; what do I have to do in pkgdb, mirrormanger, and bodhi?). We could do something simple like learn just enough rst to be able to have headings and anchors then generate static html from that using sphinx. That would give us static html with table of contents and hyperlinks for normal use and the rst text both for editing and when we need to read them using less during recovery.
-Toshio
On Mon, 2011-07-25 at 13:00 -0700, Toshio Kuratomi wrote:
On Mon, Jul 25, 2011 at 12:43:28PM -0400, seth vidal wrote:
On Mon, 2011-07-25 at 12:31 -0400, Ian Weller wrote:
On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
I've thought a bit about the SoPs and I've been wondering - do we want to move them OUT of the wiki and onto infra.fp.o?
Or have a cron job that exports them from the wiki and into static pages on infra.fp.o, instead of moving them?
It still means editing them on the wiki which, imo, is onerous and overkill for what they are. That might just be me, though, but I suspect it isn't. Wiki editing is slow and cumbersome, I've found and a brief interview with a few others in sysadmin-* bears out my suspicion..
Here's what I was thinking, actually:
infra-docs git repo on /git on infra.fp.o
docs exported on commit/push to infra.fp.o/infradocs/ or some such dir
maybe in markdown or rst - but probably just plain text to start with.
The folks who are most likely to write an SoP are going to be comfy with a text editor, I suspect.
It means if someone goes through and mauls the wiki we don't end up with broken docs in our DR location on infra.fp.o.
It also gives us an opportunity to sift through all of our docs in the transition and dump out the ones that don't matter anymore or just aren't accurate.
It would be simple to redirect all SoPs over to that site so no one gets lost.
In general I like the idea of infra.fp.o being the one place we need to recover to bring everything else back up and to know how to bring everything back up.
I think the biggest benefits of the wiki are a table of contents (Where on the ISOP:PKGDB page do I find something about removing a package?) and hyperlinks. (I'm making a new release; what do I have to do in pkgdb, mirrormanger, and bodhi?). We could do something simple like learn just enough rst to be able to have headings and anchors then generate static html from that using sphinx. That would give us static html with table of contents and hyperlinks for normal use and the rst text both for editing and when we need to read them using less during recovery.
Or, alternatively, just generate an index based on a simple 'first line of file' mechanism. Most/all is trivial.
I guess I really think I'm more likely to read the files/docs using less from a prompt.
it means I can use grep to look for things, too.
-sv
On Mon, Jul 25, 2011 at 10:24, seth vidal skvidal@fedoraproject.org wrote:
On Mon, 2011-07-25 at 10:16 -0600, Kevin Fenzi wrote:
Interesting test I saw this morning:
http://everythingsysadmin.com/the-test.html
I think we do pretty well overall, but there's some areas we could improve in.
You're right, we don't do terribly on that list at all.
We've gotten much better at remote processes and global changes.
Some of our SoP's need to be updated but in general they are documented.
I've thought a bit about the SoPs and I've been wondering - do we want to move them OUT of the wiki and onto infra.fp.o?
Well we could put them in with the CSI documentation and keep both up to date hand in hand.
I ask specifically b/c if our stuff goes sideways - recovering infra.fp.o is a priority but we may not know HOW to without being able to get to the wiki webserver, let alone the db.
Just a thought... -sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
infrastructure@lists.fedoraproject.org