Why Google is getting messaging wrong

In the past few days, latest news from Mountain View, from the power that be to abandon the Hangouts api, raised my perception that Google is getting their messaging strategy wrong - completely.

The following are my opinions on the subject, on not someone else - so burn and flame on me...

Evidence A - We need unified messaging, not splitting

Multiple message apps - hangouts, duo, what else...is the opposite of business and consumer request. Our digital life is a mess of different applications, multiple todo lists, whatever - please have all of ours sms, IM and whatever in the same place. Hangouts could do that - nicely - but Google Alphabet is taking a different direction. Tell me - do you really want that?

Evidence B - You remember BYOD, right?

BYOD means a blend of professional and personal life in the same device - my (GMail) account for Android and personal data Sync (and backup), and in the same smartphone also the professional info, the bothering appointments, the infinite work to do list - a curse for someone, a blessing for many: no more "I have different schedules on different apps",  but our only, central agenda, no more (unwillingly) forgetting of personal events while planning professionally. 

Evidence C - Google is doing business, too - but wrong

This is by no means a new one, but Google is doing big business right now, and I could name a big, big corporation making the switch to BigG in six months. The issue here is that they are taking a wrong path with the whole messaging part. When I had to join them for a call on Skype for business, all I had to do was to tell my name after clicking the link, right now I have to wait for someone to authorize me joining an hangout for which I have a regular invitation - something is clearly wrong here. And they are asking the same people not to use hangout for IM on the phone. Crazy. I see people using Whatsapp for IM purposes, even for work. 

Evidence D - You could beat all of them, if you wanted to

Think about it - whatsapp? More or less the same. Add the persistent chat, and here you are. Slack? Build team options, and channels, and you have that too. FB Messaging? Why add another option if you have a decent one already in your phone, in your browser, in your car, in every damn android system you could own.

In the end

Please, please, hire someone as a strategist for the messaging platform(s) - heck, hire me - I could do no worse than you are actually doing! But put yourself in a clear and defined position (and don't let messaging go the way of the dodo.

Packt is offering SELinux System Administration for free in their Free Learning initiative. For all who still think that disabling SELinux is one of the first steps after Fedora / CentOS installation: https://www.packtpub.com/packt/offers/free-learning

Google Closing Google Code

I guess all of you will already know this, but Google is closing Google Code (announcement here).

It's easy to say that this is another BigG Cloud Service closing, but Code demise was looming - and GitHub, BitBucket (my favourite) offers plenty of alternatives.


If you have one (ore more) projects that are using from Code, this is the time to move. A button appears to move to GitHub.

Even better, if you are the founder of a long forgotten project, take your steps...

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.

References:

• https://fedoraproject.org/wiki/How_to_create_an_RPM_package
• https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
• https://www.zabbix.org/wiki/Docs/howto/rebuild_rpms

Django e-commerce - which one to choose from?

My little brother (ok, not so little, but just to speak) got an idea for a regional ecommerce site, and asked me to support him on the software side.

While popularity of ecommerce solutions is  with PHP, I am anyway having a look at the viability of Django as an ecommerce platform.

Any suggestion? Direct experience? Comments are welcome

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.

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:

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

I change the default zone to home (my server won't go anywhere), and add dns and dhcp services to the zone.
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

http://www.thekelleys.org.uk/dnsmasq/doc.html

http://wiki.gentoo.org/wiki/Dnsmasq

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

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 

The Services running on the system are the following ones:

• 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:

dd if=CentOS-7.0-1406-x86_64-DVD.iso of=/dev/sde bs=1M

 Reboot (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_logicalvolume

I 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-release

This 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"

sudo yum install rpmdevtools mock fedora-packager

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.