Mike McKee's picture

Do you have any plans for a strictly document management turnkey solution in the near future? I have an associate in India who has a client who needs this.

Volomike

South Carolina, USA

Forum: 
Liraz Siri's picture

No definitive plans yet but we'd like to learn more about this. For example, what sort of open source components would be part of such a solution?

If there is enough interest in the community we bump up priority, but the fastest way to getting a new appliance into the library is to help build a TKLPatch for it.

Jeremy Davis's picture

It has an Open Source Community Version which has a Ubuntu 8.04 installer which should work fine on top of current TKL-Core. Or alternatively you could use the source installer on top of TKL-LAMP (along with the other requirements).

I tested it a while ago but it was overkill for my usage at that particular time, but it seemed pretty good.

No doubt there's other possibilities too.

Steven Lyon's picture

Hi, there is deffinately some interest in it.  I have a client for example who are getting killed by long file name restrictions and then need to name the files in full.  Any more joy with this thread yet?

 

Thanks

 

Steven

Mike Lesselyoung's picture

We are a small rural hospital, in desparate need of a document management system but not the cost involved.

We need to track our policies and proceedures.

Without document management, it is a nightmare.

Thanks in advance.

 

Jeremy Davis's picture

We do have a generic version control appliance; or GitLab either of which could serve the purpose, but they are more designed for code, rather than documents so I don't think they are an ideal solution to your woes. Having said that, if you wrote your policy docs in reStructuredText then they can be easily rendered in pretty html. But that's probably a job for more of a techy type person rather than an office admin...

There are quite a few open source doc managers floating about online but I have no recommendations and you'd need to install them yourself.

Mark Nottage's picture

It seems to be a popular SaaS document management platform for actual Technical Writers.    In my case, we have a team who wants to host their own documentation internally. Though on-premises installation instructions do exist, as do instructions for pulling a Docker image, neither of those sets of instructions are sufficient to carry one forward to a working self-hosted ReadTheDocs system (in my limited experience).   https://docs.readthedocs.io/en/stable/development/install.html
Jeremy Davis's picture

Thanks for the server request. I have added it to our issue tracker as a "feature request".

Although it's well worth noting that unfortunately, we have a rather large backlog of requested new appliances and we're a relatively small team, with a number of competing priorities. Currently I'm primarily focused on developing our next major release; v16.0 which is based on Debian 10/Buster. There is no ETA yet but hopefully it will be ready soon.

Currently, the only way to push this forward, would be for someone within the community (perhaps you?!) to develop the build code. Whilst it does require some Linux know-how, I'd be more than happy to provide coaching and assistance in developing that if you or anyone else is interested.

Mark Nottage's picture

Though I do have what I thought was a solid Linux, IT Infrastructure, & IT Ops background, standing up a *working* copy of ReadTheDocs is threatening to become my own personal Quixote-esqe saga!   I'm *almost* ready to designate the "ReadTheDocs stack" as too complex and finicky for consideration as an on-premises / self-hosted document management platform within my organization.   Though I must admit that declaring "defeat" will sting.   If you would point me toward the "correct" starting point for building a TKL-ready appliance, I'll endeavor to go down that road when my urge to tilt at windmills once more overcomes my gossamer tether to sanity. :)
Jeremy Davis's picture

I've never tried to set it up myself, but on face value, it appears fairly straight forward... The only thing that jumps out at me is that in the dependencies section (I looked at Ubuntu, which should be near enough for our purposes), it suggests installing 'python-dev', 'python-pip' and 'python-setuptools'. But it then goes on to explicitly create a python3 virtual env?! I assume that they actually mean the python3 versions of those packages. I.e. 'python3-dev', 'python3-pip' and 'python3-setuptools'.

As for creating a new TurnKey appliance, our build tools are bundled into an appliance of their own, called TKLDev. There is a fair bit of documentation, both here on the website and within the docs section of the GitHub TKLDev build code repo.

If you plan to have a crack at creating a new appliance, I would recommend that you have a bit of a read through that. In essence, it's actually fairly straight forward (although as per always, the devil is in the detail). Essentially appliance build code consists of a Makefile; which specifies common makefiles to use, trying to keep to the DRY (don't repeat yourself) philosophy. A plan; containing the package to install (again leverages common plans). Then conf scripts (generally bash/shell script or scripts in the conf.d dir) and overlay files (i.e. files laid over the top of the existing filesystem. At build time, packages are installed first (from both common and specific plans), then overlay files applied (common first, then local) and finally conf scripts (as per overlays).

I'm happy to assist further if you end up having a go. Although, if you're struggling to get it installed and running, then building an appliance will not make it any easier! As a general rule, documenting a stand alone install is usually the first step I take to building an appliance.

One last thing I should note though, is that the documentation talks about "the sandbox" and "root.sandbox". Unfortunately as of v14.2, that is currently broken and doesn't work as described in the docs. As we don't use it internally (it was added to make things easier for external developers) it hasn't got the priority it probably deserves, but hopefully we'll circle back to that, and fix it up at some stage...

Add new comment