I customize Linux (RHEL) Operating Systems releases for specific platforms/customers, etc... (and windows). We do kickstart installs, customize the branding, install specific packages, customize partitioning, etc...
I need suggestions on better ways to version control these OS's. Currently, we use SVN to Control the base installs (i.e. RHEL 5.6, 6.1, etc...) We don't upload the base RPMS to the Subversion server as they bloat the repo quick, only custom elements. We have YUM repos for each of the versions. A script gets run after checking out the base OS version which then performs a grab from the YUM repo for the specific package versions needed. I have been unable to find any other posts/guides doing exactly what I need to do.
We basically have to version control the package list for each OS release and do goofy things to get the packages into the base OS to create the final OS image which then gets installed via kickstart (different process for windows).
I find this cumbersome and leads to potential errors. There must be a better way! I've looked into an Artifact Repository for the non-modified components but not sure if this will significantly help me.
PS: Version control for each custom release is critical, I can't even just say RHEL 6.2 is RHEL 6.2, I have to be able to prove the custom release is the correct custom release somehow (as SVN would do).
ANY suggestions are appreciated!
Have you considered using Pulp? You can create a repository for each "release" that you want to track.
Related
I have developed (free) software, more precisely, a development environment or a code editor called "Lines". On the web I have set up installation packages for Windows and Linux, but I would like the application to be available as an "apt" package on linux systems. The easiest way to do this (and not get tired) is?
By the way, software and installation packages are available at https://creatixbih.com/lines/
Thank you.
Since I'm not really a "linux" guru, I've been trying to find an automated solution.
First you need to create a DEB package, you can read more about it here.
The easiest way to get your package into huge repositories would be to submit your package to Debian, where Ubuntu is based off. A detailed explanation can be found here.
Another good method would be to host your OWN apt repository which is being explained here
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.
I just started working for the first time with a product that's delivered via the Linux RPM mechanism, rather than as a standalone installer, and realized that this makes the test / release cycle a bit more tricky.
When I was working with installers, we would just change the build numbering in our build system to mark a build as a test or release candidate instead of a development snapshot, and tell people to install only the candidate build for testing. The problem with doing that with RPMs is that if we change the numbering system, we'll break the delivery mechanism and installed machines won't be able to tell which is the latest version of the RPM any more.
The best way I've thought of to get around this is to put the candidate RPMs in a completely separate RPM repository, but this also gets complicated because we have multiple RPMs coming from the same repository that are on different release cycles, so we'll be trying to pull the release candidate version of RPM A from the new repository while still wanting to get development snapshots of RPM B from the development repository.
This must be a pretty common issue for Linux software, so can anyone tell me the best practice ? Thanks in advance .....
One common methodology in the Linux world is to have a widely-publicized release number convention that indicates whether a build is development or release. For the Linux kernel itself, odd point releases (2.5, 2.7) are development, while even (2.4, 2.6) are releases.
A quick scan of the RPM guide seems to indicate that using a scheme like this may be the best bet.
I've written an application which as of yet is not open source and I'd like to distribute the executable across various linux distros. What's the best way to do this, I've looked a little bit at .rpm and .deb packaging but I can't find if that can be used for binaries or not. Ideally I'd like something like the PackageMaker on OS X or a regular installer on windows that will have it automatically copy into /usr/bin. Is that what .rpm and .deb packages are for or do I have to bundle a shell script that will do it automatically?
RPM and DEB packages are the two primary mechanisms for distributing binary packages in Linux. RPM is used by RedHat and its derivatives (Fedora, CentOS), while DEB is used in Debian and Ubuntu.
The .rpm and .deb files themselves are generally "dumb" archives, and are installed to the correct locations in the filesystem by pre-installed helper applications. You don't have to worry about writing scripts to install files, unless it's a very complicated application which needs special per-system configuration.
The usual patterns I see for distributing binaries are:
Release a compessed tarball (.tar.gz or .tar.bz2), and let distribution packagers worry about the details. This works well for popular applications, but if it's newly released, nobody will care enough about your application to package it.
Release as a tarball, plus RPM and/or DEB packages (depending on customer needs). Customers with a supported distribution may install the pre-made package. Anybody who's using an unusual distribution is probably happy to install from a tarball anyway.
MojoSetup is a user-friendly, perfectly cross-distro solution and nicely-licensed (zlib, very permissive). All it requires is the standard sh shell which comes with any Linux distribution. It also allows for desktop shortcuts the easy way by creating freedesktop.org spec shortcuts, which are supported by just about all graphical environments for Linux (so just dump in a PNG at different resolutions and fill in the blanks of the .desktop file).
Installers are scripted using the very simple Lua programming language and there are several example installer scripts in the Mercurial repository as well as a lengthy tutorial. There are also many years to back up its development into a lightweight cross-distro installer.
The rpm and deb will store the binaries. You'll need to have a different binaries for each distro or distro variant most likely, just because on different distros things are different like paths.
I recommend starting with the two you have rpm and deb and nail those two distro. Then maybe do a tarball for misc distros have people can extract and directory structure and copy and handle permissions on their own.
Also, for things like deb you can setup a site as a repository. That makes it easy for people to add the repo and get/install the deb in ubuntu very easily. A lot of 3rd party closed source devs do that.
That's what .rpm and .deb files do BUT you have to be sure that the installee distro has the ability to deal with the .rpm and .deb files. If you want something that's sure to run across multiple distros, where you can't be sure that they will have the right package manager, then you pretty much have to resort to the shell script method. I would advise, if you can get away with it, building your binary for both .rpm and .deb - this way, you get most of the distros covered, and you allow users to install in a way they are comfortable and familiar with, and you don't have to try to roll your own installer / uninstaller shell scripts.
You should probably provide a native package for each Linux distribution that you officially support (as you officially support them, you'll be testing on them so doing this should be trivial), and provide a .tar.gz which people can drop in for other ones.
Users can always make their own .rpm etc for some alien distribution which you don't support; but they can't complain to you unless it doesn't work on an officially supported OS.
Which OSs do you officially support? You'll obviously need to test on them all (at the very least, you'll need to pass all your regression test suite on each OS on each release).
This is of course complicated if you support multiple architectures.
We have a Linux server application that is comprised of a number of open-source tools as well as programs we've written ourselves. Ideally we would like to be able to install this application on any common Linux distribution.
In the past, we've written perl scripts to automate installs of this application. Unfortunately, due to idiosyncrasies of different Linux distros, the logic inside these install scripts gets horribly complex, and can change as new versions of each supported distro are released. Maintaining the installer thus becomes one of the most time-intensive parts of the project!
I'm looking for assistance, be it a framework, documentation, code samples, that can make this process less painful. Here are the types of things our installer needs to do:
Create user/group accounts
Create directory trees with specific ownership and permissions
Install open-source applications, potentially compiling them from source during install
Insert pre-compiled binaries, scripts, config files, and docs into specific directories
Register init-type startup and shutdown scripts
Generate encryption keys
Verify connectivity to a central server
Instead of the installer approach, I think a better way than having a single script that does it at install time is to have a build system which generates .deb or .rpm files suitable for installation on each system you have to support.
A poor man's way of going at that might be to use checkinstall, which creates packages from the files installed via 'make install'. So you'd build your app on each system and have the package magically created in the distro's native format.
I believe that most of the tasks which you describe are fairly standardized between Linux distros. In my experience, the following should work the Debian family (including Ubuntu) and the Red Hat family (including Fedora and CentOS):
Create user / group accounts - adduser command
Create directory trees - mkdir or install, or just expand a tarball
Install open source applications - Unless you have particularly esoteric needs, this should probably be left to the distro's package manager.
Install files - install, or just expand a tarball
Startup and shutdown scripts - install to /etc/init.d then symlink to /etc/rc*.d
VMware Server is freely available for Linux and does most of the tasks which you describe. It uses Perl and maybe shell for its installation and configuration, so you might see the approach that it takes.
However, speaking as a Linux admin, I strongly prefer applications that integrate with my package management system. In other words, create .deb and .rpm files, as Vinko Vrsalovic suggested. Building packages is extremely well documented:
Building RPMs for Fedora (or Red Hat or CentOS): draft documentation, RPM Guide
Building .debs for Debian (or Ubuntu): Debian Maintainer's Guide
I tried Autopackage a few years ago, don't know how universal it is but worked quite well (was the only truly universal way back then). Surely you have to provide some LSB-compatible ways of setting up proper directories on your own, but this piece of software should help you.
Though there's probably still too much diversity among linux distributions to do everything in a completely platform-agnostic way but I may be wrong.
You may want to try BitRock InstallBuilder. It is a cross platform installation tool that allows you to do exactly what you are looking for (adding users, installing services, install pre-compiled binaries, etc). Although some of the other posts mention a number of tools that you could use in your scripts, the problem is that every Linux distribution is a bit different and simple tasks like adding an user or installer a service are suddenly non-trivial when you need to do them across Debian, Ubuntu, Mandriva, RedHat, Gentoo, etc. A good cross platform installer should isolate you from all that. Many commercial open source companies like MySQL, SugarCRM, Zenoss, Jaspersoft, Groundwork etc. have built installers based on our technology exactly because of that (in addition to their regular source code tarballs, etc.) We also provide free licenses for open source projects.
Autopackage now merged with Listaller project. Documentation's not really thorough yet but seems to be working.