I would like to version control my server's configuration, in case something happens to my server.
I think crontab files themselves are not intended to be edited directly (only through crontab commands), so how would I go about versioning them? Should I version the files anyway? Is there something else I should be looking for?
I guess you're trying to automate something on a web application. It clearly goes beyond the simple fact of your server crashing. What if you want to add another front-end server for example ?
People in the ruby community came out with a pretty nice tool, "whenever" (https://github.com/javan/whenever) to solve this issue.
Namely, the proper way is not to version control the crontab. It's rather up to each app to be able to properly configure itself.
In the case of Rails applications for example, you would use a tool like Capistrano to automate your deployment. And one of the capistrano task would be to setup the correct cron jobs, thanks to whenvever. Hope this helps !
Related
I set up a GitLab self-hosted instance and its working fine, my problem right now is that I don't really understand how the frontend works. Mostly because I've been focusing on the backend and because I couldn't find documentation about it either. I wish to understand how I can comment out things I don't want to show for the user or in the overall design, change aspects and text, and overall have control of the frontend.
I'm running on Debian 9, the setup was made with Bitnami using Google VM. As far as I understand I have to manually change the files I want, but I really don't understand the structure of this type of frontend.
What language do I need to know here and where should I find the documentation, how to find the correct directory and files, etc.?
While GitLab doesn't officially support any type of "custom frontend", what you can do is:
Fork GitLab
Use the GitLab Development Kit to implement your changes
Run a Source Install of your fork
The frontend is mostly written in HAML (for the server-side bits) and Vue.js (for the client-side bits).
Note: Even an Omnibus install copies raw ruby and javascript files somewhere, and since they’re physically on the system, they can be manually manipulated and hotpatched, but that’s not really a sustainable way of introducing changes to the codebase.
I am developing opensouce project with a huge pile of dependencies, and I find Puppet a perfect tool for my requirements.
However, my target audience is not necessarily experienced with Puppet. To the point they may not be even know how web servers work. So I would like to ask the user to “run this in terminal” for the simplest case, but if the user also wants to configure some parts of my software, he would have to learn puppet. And educating them Puppet defeats the “servers for dummies” purpose of my project.
Basically, dare I say, I need Unity from the deployment world.
The thing I came up with, is to use ‘json’ as a backend for Puppet, and then write some GUI tool that would generate/modify that json using JSON Schema. Of couse, this thing will be optional and experient Puppet usets could still just use my module as is.
The questiond is, am I doing it right? Is there a solution for my problem?
Thanks in advance.
You can use Hieradata to give the ability to users to configure some parts for your "Software". you can put your hiera configuration in a git repository or build a tool to edit & update this hiera configuration.
There is some tools that you can use in order to make more easier for your users like Foreman and Puppetboard
But I think it's mandatory for your users to have a basic knowledge of Puppet so they can debug or manipulate the software.
These are some things that you can use.
Have a look at these:-
https://puphpet.com/
https://github.com/voxpupuli/puppetboard
I'm looking for some tool, which provide me possibility to dynamically (online) translate portlets in liferay. I mean, I wrote portlet in English, but people from other country may want to use it with their own language, and they can want to make translation. I know that there is Pootle tool, but I'm looking something what I can launch on Java (JBoss). There is a Jython, but I'm newbie on that, and I don't know how run pootle on jython. If someone have idea about way to solve my problem, please help.
Or maybe more simple Is there possibility to deploy pootle as war file in application server ?
regards
To your simplified question: Pootle is a Python application - AFAIK those get rarely packaged as WAR files. It might be possible, but I've never tried it...
That said, the sweet spot of Pootle is to prepare software translations and bring them back into the software development process - e.g. build. Do you want to "live update" your language files or are you ok with exporting them to your build system, then redeploying the updated plugins? If you want to do live-updates, pootle might not be the right system for you.
If you want to use the translations in the development process (e.g. in buildscripts), your real question might be "How do I install pootle?" - but for this you'd have to give some more steps that you tried, what worked and what did not work.
I never installed pootle myself, but I won't expect it to run seamlessly on a Java application server. If you've never done so as well, rather go the easy way and follow the standard installation procedure.
From a shell script, I want to detect if CC.net is currently building a project. I have the URL of the CC.net server and the name of the project.
Heck, to make it easier, I'm running this on the CC.net server itself! So any kind of local-process querying is fine.
I know I can grab the status page as HTML, and then grep that or something, but it seems awkward (especially as this is Windows). Is there an easier way?
Yes, if you don't mind writing some code you should be able to write a wrapper around ThoughtWorks.CruiseControl.Remote.dll if you poke around the source for CCTray you'll see that it is calling ICruiseManager.GetProjectStatus() which will give you a ProjectStatus array containing each of the active projects, from there you should have all you need.
My question is: How do you guys deploy the same code from whatever [D]VCS you use on multiple machines? Do you have an automated deployment system and if so what's that? Is it built in-house? Are there out there any tools that can do this automatically? I am asking because I am pretty bored updating up to 20 machines every time I make some modifications.
P.S.: Probably this belongs on ServerFault, but I am asking here because I am thinking at writing my own custom-made deployment system.
Roll your own rpm/deb/whatever for your package, set up your own repo, and have your machines pull on a regular basis. Its really not that hard to do and its already built-in to your system, is well tested, and loaded with features. You could use something like Func if you needed to push instead.
Depending on your situation deploying straight from the versioning system might not always be the best idea. You can only so much by just updating files, and mixing deployment and development probably will make the development use of the versioning system less free.
I see two alternatives that might be interesting.
Deploy from your continuous integration server. (add a task that runs after every successful build, copies over files and executes some remote commands, I'm using this to deploy to a testserver and would find it to tricky to upgrade production in such a way)
Deploy using an existing package manager. You can set up your own apt (or equivalent) repository and package the updates using apt. Have your continuous build system build apt packages but let an admin decide if the should be pushed to the update server. I think this is the only safe solution for production machines.
We use Capistrano for deployment & Puppet for maintaining the servers and avoiding the inevitable 'configuration drift' when many developers/engineers tinker with the package lists and configuration files.
Both of these programs are written in Ruby, but we use them for our PHP codebase stored in a git repository.
I use a combination of deb packages with puppet to deploy code and configure a bunch of machines.
In most projects i have been involved with the final stage has always been an scripted rsync deployment to live. so the multiple targets are built into this process.