Sunday, September 30, 2018

New version of Culmus (Hebrew) fonts released

For those of you who do some Hebrew computing, I received this from Maxim Iorsh on e-mail via the Culmus announce list. For those who don't know Culmus is an excellent set of Hebrew fonts that I've used on Linux for many years:
Many popular Linux distributions have Culmus packages in their repositories. Whether they update those packages during a release cycle and how quickly they adopt new version varies widely from distribution to distribution.

Tuesday, March 21, 2017

How Things Work Today or The Joys of Consulting

A person with company A has a concern about some work that needs to be done. They call outsource IT firm B with whom they have a contract. Firm B has nobody on staff with the required experience. Company B is big and well known. Their solution: call recruiter C who in turn checks their database and realizes that Linux systems consultant D has the experience. Hi! I'm D.

Unfortunately this is being handled like a game of telephone and the information C gave to D (me) didn't clearly explain what they needed so D (me) asked for more information. In the meanwhile I get a note from B forwarded by C that makes it very clear what is needed. Thank you, C, but... I now have to go back to C to tell them my question is irrelevant. Asking it would make me look stupid because it really isn't the issue at all. If that message gets through in time I give them what they need to present me successfully to B and A. Fortunately C did get the message before presenting D to B.

Why might this still not happen? B presents this as if A is demanding someone who has worked on the exact same hardware running the exact same application. That's why I asked an irrelevant application question in the first place. Software vendor E supports the revised environment for their application and actually has this all very well documented. I work with E for another client so I have access to their knowledge base. I can definitely solve the problem. That doesn't change the fact that I don't match on the irrelevant points of experience and they may turn around and look for someone who does.

Welcome to the world of IT consulting in 2017. Does this make sense to anyone? It doesn't to me.

Wednesday, December 21, 2016

A Holiday Gift From Conexant: an ALSA Driver For Recent Cherry Trail SOC Based Devices

Late on Monday Simon Ho of Conexant announced the release of a driver for the company's driver for CX2072X codec to the ALSA-devel mailing list. I have to add a tip of the proverbial hat to Pierre Bossart who shared the information in where I found it. According to Mr. Bossart we can expect “a follow-up machine driver soon from Intel.” The machines where sound has been a problem have Intel SST sound on the SOC which uses the Conexant codec. On those systems the "sound card" is simply not detected.

This is good news for owners of many recent tablets and notebooks running on recent Intel Atom (Cherry Trail) based SOCs. These include systems by Acer, ASUS, HP, Toshiba and probably others. It impacts Android as well as more conventional Linux distributions. Preliminary testing in the user community, though limited at this point, appears to be entirely positive.

NOTE: I'll be posting a full review of my HP x2 Detachable 10-p010nr, the latest incarnation of that company's 10” 2-in-1 device shortly. Please watch this space.

Friday, January 8, 2016

Goodbye, Debian 8.1

Goodbye, Debian 8.1 (Jessie). I tried the distro for several months because RHEL clones (Springdale Linux and CentOS, both 7.0 and 7.1) didn't like my legacy nVidia GeForce 6150 SE in this old desktop and it was a pain to fix that. The system still is good enough to do all the work I need to do and performs reasonably well. Debian seemed like a reasonable alternative. I chose to install it with LXDE as the desktop environment which is lightweight and ideal for old systems.

First, Iceweasel is not simply Firefox with the branding stripped out as is often claimed. It slows down, takes all the system resources and locks for anywhere from a few seconds to almost a minute on many websites and does this repeatedly. It did it across multiple versions. Firefox simply works without this nonsense. Of course, I can use genuine Mozilla Firefox on Debian, but only outside their package management system unless I build and maintain packages myself. Yes, other browsers offer better performance on Debian, but for some sites Firefox is my preference and sometimes I really need to test in Firefox.

Speaking of packages, their vaunted large repository would often have broken updates because of version mismatches and/or a lack of timely dependency updates. I also had to give up on Iceweasel language packs for a while because the browser was updated but the language packs were not. I had the choice of a browser with a known vulnerability that wouldn't upgrade or ripping out the language packs. Granted, I don't need browser menus in another language, but a lot of people do and there are things I wanted to test in a localized environment. I've seen this sort of really poor repository/package management in other distros, of course. I just haven't seen it much recently.

Despite the large package selection I was surprised that some very ordinary things I use regularly that are found in lots of other distros weren't in Debian. No matter what distro I use I seem to end up building packages. Debian is no different.

Then there is PulseAudio. Yes, it works. I couldn't get it to remember that I wanted line out as the default, not headphones, so I kept having to change it. Sure, that's a really minor annoyance, but it just works on most distros. User error? In this particular case quite possibly. I just couldn't be bothered to research it. I shouldn't have to spend the time to do so on something that just works in literally every other distro I've tried in recent years.

Performance was decent, but a distro designed to be lightweight can be faster on older equipment. I went back to an old favorite, Vector Linux, who have a very solid release in 7.1, and my system is faster. I'm not supporting Debian for work at the moment so there was no reason to keep it. Look, it's not a bad distro. Most of what I've described is relatively minor and entirely fixable. I don't want to tinker and I do want performance on legacy equipment. Debian 8.1 is simply not the best choice for me.

Monday, October 19, 2015

List of Linux System Hardening Resources

My recent post about how quickly newly commissioned Linux systems can be attacked and possibly compromised led to a bunch of e-mail queries about resources which explain how to lock down a variety of Linux distributions. Most such guides are distribution specific because, while the basic principles are always the same, there are significant differences between distributions and even versions of the same distribution that make writing a generic guide difficult at best.

I did compile a list which I added to the comments. However, based on the number of questions I've received I thought it would be best to publish the list as a blog post, something people could easily find and bookmark, with some additions to what I originally posted. I've limited this list to distributions commonly used in businesses (large and small), academia, and in non-profits. I have not included specialized distributions, including those designed for use by security professionals. Most of these distributions also are excellent choices for personal use.

Red Hat Enterprise Linux / Centos / Scientific Linux / Springdale Linux




Wednesday, October 7, 2015

Linux Security: Lock Down a New System Immediately

PCWorld recently published an article about Linux botnets launching DDoS attacks. The attackers find and exploit poorly secured Linux systems. Some Linux users have a fairly cavalier attitude about security, assuming the supposedly superior design of the OS somehow protects them. It doesn't. Now that Chromebooks outsell Windows laptops and Amdroid devices are ubiquitous the days when Linux was a secondary target for malware are long gone. Linux' prominence in both the server room and on consumer devices make it a prime target.

How quickly will a newly commissioned system be attacked? Here's my recent experience. I did a build of a webserver with CentOS 7.1 and Drupal 8. That went smoothly. Then I installed all the latest patches. On to configuring and hardening the server. The first time I issued a su command to allow me to configure sudo I got a message about failed logins. I looked at the logs and sure enough, someone was already trying to break in with a scripted brute force attack. I immediately configured ssh to disallow root login and to disconnect after three failed attempts. That slowed but did not stop the attacks. OK, I checked the IP address they were coming from, knowing full well it might be spoofed, and found the owner was a French ISP. To satisfy my curiosity I put in a temorary firewall rule to disallow that IP range and the attack stopped and did not resume. So... either the IP address was not spoofed and some script kiddie was trying to break in from their actual connection or else the attack came through a proxy server with an IP address in that range. Cute.

Anyway, I finished my usual tasks for hardening a server and Apache, uploaded my backed up files and put them in the appropriate places with the appropriate permissions. My idea of hardening Apache includes both mod_evasive and mod_security with a current rule set. My idea of securing a server includes blocking pretty much all inbound connections not needed by either the web server, software used on the website or SSH.

I should also add that IP address blocking, up to and including geolocking, is generally not an effective defense. Knowledgeable hackers use proxies. Many change their apparent IP addresses frequently. Blocking IPs, even at the firewall level, is a lot like playing Whac-a-Mole. The attack simply continues from a different IP in short order. The brute force attacks I'm still experiencing are trying to login as root and since remote root logins are disabled that simply won't work. However, the excess traffic to my server continues and there is relatively little I can do about it.

How long between my rebuild and the start of the attacks? A few minutes. Such is life on the Internet today. The first thing anyone should do with a new system, any system, is lock it down.

Friday, May 30, 2014

32-bit Enterprise Linux Still Matters

I've been testing the Red Hat Enterprise Linux 7 Release Candidate. One thing that stuck out right away was the lack of a 32-bit x86 build. In last week's DistroWatch Weekly Jesse Smith questioned the need for such a build, which is only useful on legacy hardware, in the enterprise. He wrote:
"Something which caught my attention while reading this question was the requirement for a 32-bit operating system with newer software than Red Hat Enterprise Linux 6 offers. It seems unusual that someone would want new software versions, enterprise support and a 32-bit operating system. New software and legacy hardware (or new software and enterprise environments) rarely go together and it might be worth looking into whether these criteria are really necessary."
While I certainly understand Jesse's point about 32-bit being legacy hardware, there are still many use cases where 32-bit and current enterprise quality software and OS are necessary. Many current Linux apps are still very light and can run very well on rather old hardware, both in the server room and on the desktop.

I've done a lot of support of government servers and they run for about forever, as in until they serve no further use. Even retired, old servers are often repurposed and put back into service due to budget restrictions and/or long lead times to order new equipment under the required procedures for government procurement. In the United States this is especially true at the state level. When a server is repurposed it is usually reloaded with the current enterprise standard Linux distrubution release and applications, not legacy releases. That's one common use case.

Non-profits and small businesses often get by with older equipment as well, and in the case of non-profits it may even be donated second hand equipment that was no longer useful in it's former commercial enterprise home. Once again, a 32-bit OS and current software makes sense in cases like this.

My personal hope is that the free enterprise Linux clones will take Red Hat's 64-bit sources and create a 32-bit version. It isn't hard to do but it is time consuming. CentOS has already made clear they will release a 32-bit build(see comment by developer Johnny Hughes below), which leaves Scientific Linux and Springdale Linux.

[Note: This article was expanded from my comments on DistroWatch Weekly, Issue 560.]