Re: A Linux/OSS Support Business - Linux

This is a discussion on Re: A Linux/OSS Support Business - Linux ; Jim Richardson wrote: > > The problem with outsourcing that stuff, at least at the admin level, is > the ramp up time. Similar with bespoke programming, at least in my > limited experience, but for some projects, it definitely ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Re: A Linux/OSS Support Business

  1. Re: A Linux/OSS Support Business

    Jim Richardson wrote:
    >
    > The problem with outsourcing that stuff, at least at the admin level, is
    > the ramp up time. Similar with bespoke programming, at least in my
    > limited experience, but for some projects, it definitely can work.


    You've hit the nail on the head with that one. That is why part of
    our plan includes a detailed knowledge base with data specific to
    each server that is part of the support contract. Not a perfect
    solution, but something that should greatly reduce ramp-up time.

    Again, this is growing out the informal solutions we already have
    in place. One of our biggest challenges with our clients is
    documenting all the oral tradition and lost tribal knowledge that
    tends to disappear when an employees leave. We've been leveraging
    wiki technology to good effect.

    Thad
    --
    Yeah, I drank the Open Source cool-aid... Unlike the other brand, it had
    all the ingredients on the label.

  2. Re: A Linux/OSS Support Business

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Thu, 20 Dec 2007 13:53:35 -0600,
    thad05@tux.glaci.delete-this.com wrote:
    > Jim Richardson wrote:
    >>
    >> The problem with outsourcing that stuff, at least at the admin level, is
    >> the ramp up time. Similar with bespoke programming, at least in my
    >> limited experience, but for some projects, it definitely can work.

    >
    > You've hit the nail on the head with that one. That is why part of
    > our plan includes a detailed knowledge base with data specific to
    > each server that is part of the support contract. Not a perfect
    > solution, but something that should greatly reduce ramp-up time.
    >
    > Again, this is growing out the informal solutions we already have
    > in place. One of our biggest challenges with our clients is
    > documenting all the oral tradition and lost tribal knowledge that
    > tends to disappear when an employees leave. We've been leveraging
    > wiki technology to good effect.
    >
    > Thad



    bingo. Wiki's make handling tribal knowledge transfer a whole lot
    better, and the easier to use the better. Twiki is good, and has a lot
    of plugins, and tends to be fast. Unfortunately, we have an older
    version of Twiki at work, and the upgrade path from $QUITE_OLD to $NEW
    wrt the existing data is rather tortuous.

    I find that the tribal knowledge aspect is the least considered in these
    sorts of things. I have been brought in as a consultant in companies
    that had "let go" half their IT staff a few months earlier, and found
    that there were a lot of reasons that dropping that staff was a piss
    poor choice.

    Tribal knowledge can be limited with things like Wikis (if they are
    used) and open communications, and standardizing on say, RH/CentOS or
    Debian or Suse or something. Don't mix and match, and set up procedures
    for everything.


    We use cfengine here for some things, but with the pxe boot setup now,
    and the kickstart config system we have, that's probably going to go
    away soon. It's a tad too heavy for our needs anyway.

    Jim, busy working to make himself a replacable cog

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHatd/d90bcYOAWPYRArc6AJ0WMBPCgaXV4RrQWMWddmnemdRvXQCgh1 FW
    w9tWxlqUFgeDdcO4gy5Mt1s=
    =D5Sd
    -----END PGP SIGNATURE-----

    --
    Jim Richardson http://www.eskimo.com/~warlock
    Intel is not Microsoft. They have a very good history of shipping what
    they promise (with a few exceptions).
    Erik Funkenbusch in comp.os.linux.advocacy

  3. Re: A Linux/OSS Support Business

    Jim Richardson wrote:
    >
    > I find that the tribal knowledge aspect is the least considered in these
    > sorts of things. I have been brought in as a consultant in companies
    > that had "let go" half their IT staff a few months earlier, and found
    > that there were a lot of reasons that dropping that staff was a piss
    > poor choice.


    Yup, similar experience here. My major admin clients are places that
    downsized the internal staff.

    > Tribal knowledge can be limited with things like Wikis (if they are
    > used) and open communications, and standardizing on say, RH/CentOS or
    > Debian or Suse or something. Don't mix and match, and set up procedures
    > for everything.


    I stepped into one client a while ago to find a mish-mash of systems.
    A mix of Debian and RedHat Linux at various version levels, a legacy
    Win2K box, and even an old Sun server. Some of the systems had
    fallen far enough behind on upgrades that legacy apt repositories
    were not even an option anymore. Some of the hardware was so old
    that hardrives and power supplies were beginning to randomly die.
    The Windows and Sun servers are now gone, and I've been replacing
    other servers one at a time with new hardware and standardizing on the
    latest stable Debian. We've made an in-house wiki to document all the
    server configs and how to handle various issues and maintenance tasks.
    I find the better we document things, the more I can hand off tasks to
    lower level techs, which frees up my time for only the most challenging
    issues.

    > We use cfengine here for some things, but with the pxe boot setup now,
    > and the kickstart config system we have, that's probably going to go
    > away soon. It's a tad too heavy for our needs anyway.
    >
    > Jim, busy working to make himself a replacable cog


    Yup, I take every opportunity to automate repetitive admin tasks.
    I will soon replace myself with a collection of bash and perl
    scripts.

    Thad
    --
    Yeah, I drank the Open Source cool-aid... Unlike the other brand, it had
    all the ingredients on the label.

  4. Re: A Linux/OSS Support Business

    On Thu, 20 Dec 2007 13:53:35 -0600, thad05@tux.glaci.delete-this.com wrote:

    > Jim Richardson wrote:
    >>
    >> The problem with outsourcing that stuff, at least at the admin level, is
    >> the ramp up time. Similar with bespoke programming, at least in my
    >> limited experience, but for some projects, it definitely can work.

    >
    > You've hit the nail on the head with that one. That is why part of
    > our plan includes a detailed knowledge base with data specific to
    > each server that is part of the support contract. Not a perfect
    > solution, but something that should greatly reduce ramp-up time.


    Isn't that a security issue? I mean, in most companies, the information
    you would want to keep "common" among your "freelancers" would contain
    sensitive information that would usually be on a "need to know" basis.

    Making it "public" to everyone in your company would seem like a breach of
    customers trust.

  5. Re: A Linux/OSS Support Business

    Erik Funkenbusch wrote:
    >
    > Isn't that a security issue? I mean, in most companies, the information
    > you would want to keep "common" among your "freelancers" would contain
    > sensitive information that would usually be on a "need to know" basis.
    >
    > Making it "public" to everyone in your company would seem like a breach of
    > customers trust.


    Data is not made public to everyone. In our current implementation,
    various parts of the wiki are restricted to specific groups of users,
    and of course things like passwords are not kept in the knowlegebase.
    A freelancer would only gain access to server specific info when
    taking on admin responsibility for that server.

    We are also exploring ways of making the security much more granular,
    including use-once password systems and complete keylogging of all
    admin sessions (this is also useful for capturing solutions to dump
    into the knowledgebase).

    Of course it goes without saying that you still need to fully vet
    your freelancer candidates and cover your bases from an indemnity/
    liability standpoint.

    Thad
    --
    Yeah, I drank the Open Source cool-aid... Unlike the other brand, it had
    all the ingredients on the label.

  6. Re: A Linux/OSS Support Business

    thad05@tux.glaci.delete-this.com wrote:

    > We've made an in-house wiki to document all the
    > server configs...


    Thad... which wiki software did you decide on?
    --

    Jerry McBride (jmcbride@mail-on.us)

  7. Re: A Linux/OSS Support Business

    * thad05@tux.glaci.delete-this.com fired off this tart reply:

    > Again, this is growing out the informal solutions we already have
    > in place. One of our biggest challenges with our clients is
    > documenting all the oral tradition and lost tribal knowledge that
    > tends to disappear when an employees leave. We've been leveraging
    > wiki technology to good effect.


    We've been thinking about the wiki at work, too. We tend to document
    formally, but there's a lot of knowledge that still doesn't get written
    down, but might if it were as easy as writing some code .

    --
    Tux rox!

  8. Re: A Linux/OSS Support Business

    Jerry McBride wrote:
    > thad05@tux.glaci.delete-this.com wrote:
    >
    >> We've made an in-house wiki to document all the
    >> server configs...

    >
    > Thad... which wiki software did you decide on?


    Actually, we are using two different versions based on what each
    client already had in place or at least some experience with. They
    are Docuwiki and Twiki if memory serves. Of course we will
    standardize on one version if we roll out a formal service, and
    it might not be either of those. I need to write some formal
    requirements and then research the alternatives.

    Thad
    --
    Yeah, I drank the Open Source cool-aid... Unlike the other brand, it had
    all the ingredients on the label.

  9. Re: A Linux/OSS Support Business

    Linonut wrote:
    >
    > We've been thinking about the wiki at work, too. We tend to document
    > formally, but there's a lot of knowledge that still doesn't get written
    > down, but might if it were as easy as writing some code .


    Being web based, a wiki lends itself to collaborative use more
    than the a shared drive full of word processor docs.

    Thad
    --
    Yeah, I drank the Open Source cool-aid... Unlike the other brand, it had
    all the ingredients on the label.

  10. Re: A Linux/OSS Support Business

    thad05@tux.glaci.delete-this.com wrote:

    > Jerry McBride wrote:
    >> thad05@tux.glaci.delete-this.com wrote:
    >>
    >>> We've made an in-house wiki to document all the
    >>> server configs...

    >>
    >> Thad... which wiki software did you decide on?

    >
    > Actually, we are using two different versions based on what each
    > client already had in place or at least some experience with. They
    > are Docuwiki and Twiki if memory serves. Of course we will
    > standardize on one version if we roll out a formal service, and
    > it might not be either of those. I need to write some formal
    > requirements and then research the alternatives.
    >
    > Thad


    If you find it appropriate, could you apprise me of your final decision on
    wiki software? I'd be very interested in what you decide.

    Thanks.



    --

    Jerry McBride (jmcbride@mail-on.us)

  11. Re: A Linux/OSS Support Business

    Jerry McBride wrote:
    >
    > If you find it appropriate, could you apprise me of your final decision on
    > wiki software? I'd be very interested in what you decide.
    >
    > Thanks.


    Sure, I'll probably write up something on the entire suite of tools
    that we assemble and post it on my website. I'll let people know
    about it hear when I do.

    Thad
    --
    Yeah, I drank the Open Source cool-aid... Unlike the other brand, it had
    all the ingredients on the label.

  12. Re: A Linux/OSS Support Business

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Thu, 20 Dec 2007 17:53:51 -0500,
    Erik Funkenbusch wrote:
    > On Thu, 20 Dec 2007 13:53:35 -0600, thad05@tux.glaci.delete-this.com wrote:
    >
    >> Jim Richardson wrote:
    >>>
    >>> The problem with outsourcing that stuff, at least at the admin level, is
    >>> the ramp up time. Similar with bespoke programming, at least in my
    >>> limited experience, but for some projects, it definitely can work.

    >>
    >> You've hit the nail on the head with that one. That is why part of
    >> our plan includes a detailed knowledge base with data specific to
    >> each server that is part of the support contract. Not a perfect
    >> solution, but something that should greatly reduce ramp-up time.

    >
    > Isn't that a security issue? I mean, in most companies, the information
    > you would want to keep "common" among your "freelancers" would contain
    > sensitive information that would usually be on a "need to know" basis.
    >
    > Making it "public" to everyone in your company would seem like a breach of
    > customers trust.


    I can't speak for Thad, but the Wiki we use, interfaces with ldap, and
    you can limit who sees what on a very fine grained level.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHa/wTd90bcYOAWPYRAm0XAJ9P3W7VtSq3H6n2O03FaQrs5gwf0gCg yyRP
    UpXZdy+Et00wJG4+Uj/Gy64=
    =CaiF
    -----END PGP SIGNATURE-----

    --
    Jim Richardson http://www.eskimo.com/~warlock
    "The Secret of Zen lies in just two words: Not Always So.."
    - Shunryu Suzuki

+ Reply to Thread