Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts
Wednesday, November 18, 2015
Friday, January 30, 2015
Rebuilding Fedora Packages for CentOS - A workflow
Why Rebuilding Packages
With the upgrade to CentOS 7, some of the services I was using are no more present in CentOS repositories. An example of this is BackupPC and ddclient, which I use for services and reachability of the machine.
I could install them through normal installation (tar.gz extraction,make config, make) but I feel this both as a waste and a danger. First of all, everybody using this will be doing the same, which is a wasted effort. Second, I adopted CentOS for stability, which also means repeatability of configuration. Third, it's fun and satisfactory, run a yum install and having everything in place.
Fedora Compatibility
Upstream (aka "Red Hat Enterprise Linux 7") is mostly a combination of Fedora latest release (I guess from F18 onward), so in CentOS we find most of the novelties which have been developed in the last two to three years:
- Systemd
- Journal
- FirewallD
- Gnome 3
And a lot of other plumbing that I am forgetting about. Right now, repackaging an F21 spec for CentOS 7 is quite easy: these two distributions will slowly diverge in the next few years.
My Workflow
I adopted the following workflow: I assume that rpm development setup has been completed for the steps to succeed.
1 - Download source package
Downloading source packages is quite easy: install yum-utils on your fedora pc, and launch yumdownloader --source $packagename, eg:
yumdownloader --source ddclient
2 - Install src package
Copy the package on the CentOS machine, where a rpm dev environment is setup, and, as non-root account, install the src package. You will find the SPEC file in the ~/rpmbuild/SPECS directory, and source and patches in ~/rpmbuild/SOURCES.
3 - Adapt the SPEC file
You should edit the SPEC file, at least adding the CHANGELOG line in which you can write who you are, the date, and what you did. Experienced packagers can update the source files, apply further pathecs and so on. I suggest you check the following stuff:
- the "Release:" line will contain a number, followed probably by %{?dist} macro, which will get substituted by the distribution abbreviation (el7 for centos, f21 for fedora). If not, correct it
- Check the description and version, check with upstream if minor releases have been done, and if you wish to release a newer version of the package
4 - Rebuild the src package
Just type rpmbuild -bs $SPECFILE and you will have a new src package in ~/rpmbuild/SRPMS
5 - Mock build the package
Mock (yum install mock) will:
- create a chroot environment in /var/lib/mock/$target_architecture (in our case, epel-7-x86_64)
- download build time packages
- build the package in the chroot environment
- have a log of activities and the built packages in /var/lib/mock/$target_architecture/result
all of this simply entering: mock $src_package (eg - mock ~/rpmbuild/SRPMS/ddclient-3.8.2-2.el7.centos.src.rpm )
6 - Install the package
Time to test with a local installation of the package. Or you can deploy to your local repository for testing.
That's it. If you feel it, try to have a look at copr for distribution of your packages.
That's it. If you feel it, try to have a look at copr for distribution of your packages.
References:
Sunday, January 11, 2015
Upgrading to CentOS 7 - Part Two
DHCP / DNS Server (dnsmasq)
My home network is quite limited (two to three workstations, plus android phones, android tablet, an ipad mini, an HP networked printer / scanner, a raspberry pi controlling the water sprinklers in the garden, a smarttv...), so instead of setting up a complete bind / dhcp solution, I prefer a simpler dnsmasq setup.
On CentOS is simple, just:
sudo yum install dnsmasq dnsmasq-utils
I add the following configuration in /etc/dnsmasq.d/main.conf
#Centos 7 Changed the interface naming
interface=enp2s0
domain-needed
bogus-priv
server=/local.lan/0.0.0.0
local=/local.lan/
expand-hosts
domain=local.lan
resolv-file=/etc/resolv.conf.dnsmasq
# These are arbitrary
dhcp-range=xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx,12h
dhcp-host=00:00:00:00:00:00,HPxxxx,xxx.xxx.xxx.xxx # Printer
# dhcp router option
dhcp-option=option:router,xxx.xxx.xxx.xxx
dhcp-option=44,0.0.0.0 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
dhcp-option=45,0.0.0.0 # netbios datagram distribution server
dhcp-option=46,8 # netbios node type
dhcp-option=vendor:MSFT,2,1i
dhcp-authoritative
#I check with logging everything is working ok
log-queries
log-dhcp
What I am saying here:
- the interface dnsmasq will bind on is enp2s0 (beware the network interface name changing) - interface
- no DNS request will be forwarded if plain name or non routed address space - domain-needed / bogus-priv (docs say that these option make me a better netizen...)
- The name server for "local.lan" (internal domain) will be 0.0.0.0 (this server) - server
- The "local.lan" will be answered through /etc/hosts or dhcp leases - local
- A domain will be added to simple entries in a /etc/hosts file - expand-hosts
- The local domain (domain dhcp option) and name of the domain for the previous option - domain
- The DNS to forward requests to are in an external file, not in the resolv conf - resolv-file
Remaining options enable the dhcp server (dhcp-range), set a specific address for the netwok printer (dhcp-host), and set some options for the network.
Additional DNS / DHCP information
For my purposes, the little server should resolve names in the network as well. This works, but to resolve self, I've found that /etc/hosts it's not enough. I have to put 127.0.0.1 as the first nameserver, so for my setup I modify the /etc/sysconfig/network-scripts/ifcfg-enp2s0 with the following option:
- DNS1=127.0.0.1
This is because at boot (or network restart) settings inside this file will replace what is in the /etc/resolv.conf file.Please remind that my setup is for a small server with fixed IP address (configured as such during installation).
In the external file (option resolv-file above) the format will be the same of the /etc/resolv.conf file, in my case:
nameserver 8.8.8.8
nameserver 8.8.4.4
Yes, so now you know - I use Google's DNSs....
After that sudo systemctl enable dnsmasq and sudo systemctl start dnsmasq.
After that sudo systemctl enable dnsmasq and sudo systemctl start dnsmasq.
ToDo
DNS Security Extension (DNSSEC) should be an add on in network security, and good practice - current version of dnsmasq in CentOS is 2.66, last stable version is 2.72, first version with DNSSEC is 2.69. When setup is complete, I will explore the option to create an updated package. This will add dependencies on nettle and gmp libraries, both of them are already in the repositories.
The Firewall (firewalld)
Among other things, CentOS 7, or better, RH 7 changed the firewall. While it would be easier to scale back to IPTables, I see the rationale in FirewallD - updating rules while not dropping connections. Not exactly my use case, but still an interesting direction.
Keeping up with firewalld what I did was:
Additionally, just to be coherent with NetworkManager settings, I add the following line to the /etc/sysconfig/network-scripts/ifcfg-enp2s0:
That's it.
Keeping up with firewalld what I did was:
sudo firewall-cmd --set-default-zone=home
sudo firewall-cmd --permanent --zone=home --add-service=dns
sudo firewall-cmd --permanent --zone=home --add-service=dhcp
sudo firewall-cmd --permanent --add-interface=enp2s0
sudo firewall-cmd --reload
Additionally, just to be coherent with NetworkManager settings, I add the following line to the /etc/sysconfig/network-scripts/ifcfg-enp2s0:
- ZONE=home
That's it.
References
https://wiki.archlinux.org/index.php/Dnsmasq
https://fedoraproject.org/wiki/FirewallD
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html
https://fedoraproject.org/wiki/Systemd
https://fedoraproject.org/wiki/FirewallD
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html
https://fedoraproject.org/wiki/Systemd
Tuesday, January 06, 2015
Upgrading to CentOS 7 - Part One
The Issue
A couple of weeks ago, I decided to update my home server from CentOS 6.x to CentOS 7.x. No real motivation for the move, since my home server was working flawlessly, but I had a desire to keep it in par with the latest and the greatest.
In reality, using Fedora for my laptop, I wanted to (somewhat) unify technologies used in both machines: the dreaded SystemD, the new journal, Gnome 3.x.
Speaking of these, if I can tell my opinion, SystemD (mostly) just works, both for the desktop and the server. The journal is a non-issue, and for Gnome 3 - well, having been a fan of KDE for a long time, and a Windows user sometimes for my job, while in these environments I usually find myself trying to reach the Overview moving the mouse cursor in the upper left corner (or pressing the windows key).
Upgrade or Clean Install?
I tend to prefer the latter during some release cycles of Fedora, and between major upgrades in CentOS. Why? Too much cruft. Especially the server has multiple roles for me (internal yum repo, backup server, Samba Server, AFS Server), and for some of these services I want to start clean again, while documenting (through this blog, by the way) what I am doing.
As a pet project, I would like to replicate this configuration steps through SaltStack, so starting from a clean install allows me the really keep everything under control.
Additionally, I want to move most of my volumes from an ext4 fs to XFS; my preference would have gone to BTRFS (especially thinking to the RAID 1 setup I have, and snapshotting the BackupPC data volume) but I had a couple of crashes in Fedora that warned me about the testing status of the filesystem.
The Environment
My Home Server is an HP Proliant N36L (the older ones) with an AMD Athlon II Neo CPU (x86_64 architecture, of course). My current configuration is as follows:
- One 250 gb disk for OS
- Two 2TB disks in RAID 1 configuration
- 8 GB of ECC RAM
- dnsmasq (for simple dns / dhcp )
- BackupPC (continous backup of client machines)
- Apple File Share (yes, my wife got a MacBook)
- Samba Shares
- Apache for Yum Repo
How Did I proceed?
The RAID volumes (it's actually RAID + LVM) won't be touched; so I copied some files over there before beginning. Cloud Backup was up to date (I use Crashplan), such as some offline backups I use. Time to go.
Downloaded the CentOS 7 torrent, started the rtorrent client.
After that I dd'ed the image. The reference is at CentOS wiki but the command is the following:
After that I created a new Volume to (teporarily) move stuff around, while transforming previous filesystems from ext4 to XFS.
Recreating the volumes with the new file system is as simple as:
After that I added, as I always do, the EPEL repository for additional software and dependencies:
What I am going to do: looking for additional sources or, in bad luck, repackaging the fedora packages.
The things to keep an eye on are the systemd enabled services / packages, and general compatibility with the system.
For building packages on the system:
dd if=CentOS-7.0-1406-x86_64-DVD.iso of=/dev/sde bs=1MReboot (in BIOS you should have enabled the boot from USB), and install a base system. No issue here, everything was smooth. I should say that I find the new installer graphically clean and pleasant, apart from the "select disk / partition" part which is mostly unclear from a user point of view (Máirín did a great job here, but I am still unsure, after F18-19-20-21, where, if and when I will have the option to review partitioning).
After that I created a new Volume to (teporarily) move stuff around, while transforming previous filesystems from ext4 to XFS.
Recreating the volumes with the new file system is as simple as:
mkfs.xfs -f -L $label /dev/vg_volumegroup/lv_logicalvolumeI added the -f (force) option because mkfs stops when detects an already created file system on the volume.
After that I added, as I always do, the EPEL repository for additional software and dependencies:
sudo yum install epel-releaseThis works because CentOS now adds the epel-release package in the extras repository.
Package rebuilding preparation
CentOS (as RedHat) does not have all the packages that, eg, Debian has. This is a weak spot but, for my setup at least, an easy one to fix.What I am going to do: looking for additional sources or, in bad luck, repackaging the fedora packages.
The things to keep an eye on are the systemd enabled services / packages, and general compatibility with the system.
For building packages on the system:
sudo yum groupinstall "Development Tools"
After that, execute rpmdev-setuptree to set the paths. I'll state the obvious, here: all package building activities should be done with a non-root account.sudo yum install rpmdevtools mock fedora-packager
Thursday, July 23, 2009
Building RPMs, part two - Pinax
Ok, so now we have the environment complete. First thing I want to package is Pinax. This is a nice little collection of Django applications which add some required stuff for most of web based applications.
On the link above you will find all the info for the project, so let's start. We will build the release version of Pinax (for development versions I have a side project, which I will show you at right time). Please note - all the release used are current for the day this entry has been written.
Download pinax version 0.5.1 from here and put it in rpmbuild/SOURCES. After that:
Rpmdev-newspec creates the skeleton for a new spec file named pinax. The -t python option tells to create a skeleton with some python definitions in it (python definitions are laid out according to this wiki entry on the Fedora Project Wiki); you can see which skeletons are available looking in '\etc\rpmdevtools'.
Why Python? Well, my guess is that being DJango a Python framework, you know....
Let's look at the spec file and put some info into that. You can use any editor for the file (I use geany, fast and lightweight).
On the link above you will find all the info for the project, so let's start. We will build the release version of Pinax (for development versions I have a side project, which I will show you at right time). Please note - all the release used are current for the day this entry has been written.
Download pinax version 0.5.1 from here and put it in rpmbuild/SOURCES. After that:
cd ~/rpmbuild/SPECS
rpmdev-newspec -t python pinax
Rpmdev-newspec creates the skeleton for a new spec file named pinax. The -t python option tells to create a skeleton with some python definitions in it (python definitions are laid out according to this wiki entry on the Fedora Project Wiki); you can see which skeletons are available looking in '\etc\rpmdevtools'.
Why Python? Well, my guess is that being DJango a Python framework, you know....
Let's look at the spec file and put some info into that. You can use any editor for the file (I use geany, fast and lightweight).
# sitelib for noarch packages, sitearch for others (remove the unneeded one)
%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
%{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
Name: pinax
Version:
Release: 1%{?dist}
Summary:
Group: Development/Languages
License:
URL:
Source0:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:
BuildRequires: python-devel
Wednesday, July 08, 2009
Building RPMS, part one
The following is an excerpt from the IRC Packaging Lesson ; in red instructions for root (please use sudo - never use a system as root):
The last command will setup the following directories:
This directory will contain the build of the source code you want to package. Roughly equivalent to the directory where you tar xjf source.tarball.bz2 ; cd source.tarball ; .configure ; make
The directory where the package will be built.
The rpm produced will end in this directory. This is the binary rpm, the one you want to install in the system to use that cute application of yours.
Tarballs will end up here. These are the .gz or bz2 downloaded to build the application; usually contains source files, in the common autotools format.
Spec files are the files which define how to package software, which dependencies to look for, and some more stuff. It's the only file you need (apart from source code) to really build a package.
SRPMS files are RPMS which contain source and SPEC file to rebuild packages with rpm.
OK, right now I will close the entry. A new one in a few days.
- yum groupinstall development-tools
- yum install rpm-build rpmdevtools
- rpmdev-setuptree
The last command will setup the following directories:
BUILD
This directory will contain the build of the source code you want to package. Roughly equivalent to the directory where you tar xjf source.tarball.bz2 ; cd source.tarball ; .configure ; make
BUILDROOT
The directory where the package will be built.
RPMS
The rpm produced will end in this directory. This is the binary rpm, the one you want to install in the system to use that cute application of yours.
SOURCES
Tarballs will end up here. These are the .gz or bz2 downloaded to build the application; usually contains source files, in the common autotools format.
SPECS
Spec files are the files which define how to package software, which dependencies to look for, and some more stuff. It's the only file you need (apart from source code) to really build a package.
SRPMS
SRPMS files are RPMS which contain source and SPEC file to rebuild packages with rpm.
OK, right now I will close the entry. A new one in a few days.
Subscribe to:
Posts (Atom)