Brad Ideas - Sysadmin - Comments

great Brad idea

Sairy — Sat, 20 Oct 2007 00:44:06 -0700

I like this. It makes a lot of sense. And I think you're right on with the mobile point as well. I've run into that problem in the past especially when passwords have characters that aren't easy to find with mobile keyboard interfaces.

What irritates me (as a user) more than delays, FWIW, are the sites that assume your username is correct and default to telling you the password is wrong vs. noting that it could be either one. I've wasted much more time hammering on passwords when the username was incorrect than I have from typos in the passwords. (Not that the delays aren't a nuisance.)

My credit union has a simple

Charles Merriam — Thu, 18 Oct 2007 22:24:05 -0700

My credit union has a simple password. After three tries, you need to talk to the branch.

Yes, be careful

brad — Wed, 17 Oct 2007 11:44:34 -0700

Yes, I don't say one should not be careful in design of these systems. I just rant about making a choice that frustrates the legitimate user as well as the attacker, when there could be choices to only frustrate the attacker.

Keeping usernames secret requires a tradeoff. Doing so can frustrate users, who may think they have got their password wrong (and keep retrying it until they get locked out) when actually they have their userid wrong. On the other hand, attackers may have various easy methods available to test usernames independently on many of today's sites, in which case hiding them helps nothing. (Many sites will let you enter usernames to get the password emailed without also asking for the email, for example, or put usernames in public web pages and URLs. In addition, it is very, very common for users to keep the same username over many systems.)

Can be source of security vulnerabilities too

Tim Farley — Wed, 17 Oct 2007 04:26:55 -0700

If you're not careful how you implement the time delay, you can create a security vulnerability with this too.

There was an old version of Novell NetWare that would delay the reply packet if the request contained a bad password. However, it did NOT also do the same thing on bad username. As a result, you could brute-force a list of usernames for that server by simply watching for whether the delay occurred.

It's merely an information leak, but it could be an useful early step in an attack.

Alias?

Moz — Fri, 27 Apr 2007 22:04:41 -0700

Surely rather than rename (or as well as) you'd just want an "alias" command of some sort. Being able to say BlogFartz 4.9.2 is also SpellCheckMyBlog 2.4.0.27365 is probably only going to happen a few million times, so it is probably worth including.

But I admit that I'm a complete knucklehead on this stuff, I invariable spend much time cursing when I have to upgrade anything significant.

Linux needs to be easier than Microsoft Windows Operating Sys...

Francisco — Fri, 30 Mar 2007 23:58:07 -0700

Hi.

On Microsoft windows operating system you just install a new program and there is no a need to worry what dependencies you will need because the installer already have those DLL's (Dinamic Link Libraries) which are dependent for the new program already included within the installer it self and the installer automatically copies these DLL's to the %windir%\system32 folder. Why cant it be the same for linux, why cant it be all this easy for installing new programs, a linux program installer (the RPM's or DEB's) should automatically satisfy any dependencies for the said program to be installed and not having to gun down the responsibility towards the users in having to download all these dependencies on the internet. That way no one would be interested in switching to Linux from Windows XP, its just way too complicated for the average joe.

>>>LINUX NEEDS TO BE SIMPLIFIED TO THE POINT IT IS EASIER TO RUN AND MAINTAIN THAN MICROSOFT WINDOWS OPERATING SYSTEMS<<<

finally someone with the same problem :)

David — Sun, 18 Mar 2007 07:12:18 -0700

Thanks for your article. It's hard to find articles that go as deep in the dependency problem. For the moment I'm having this problem. I want to run kdenlive on kubuntu breezy. And I found there is no proper way to do it for a non technical linux user as I am. No breezy package in the backports and the klikable package (http://klik.atekon.de/)does not run on my system because it can't find an rpm on the packmanrepository. Sometimes I think I'm the only one who run a linuxdistribution longer than 1 year :)...and run their system with a minimum of updates because I don't have a broadband internetconnection.

I do use apt

brad — Sat, 09 Dec 2006 18:42:32 -0800

In fact, I even use it on Fedora as well as Debian and Ubuntu.

The problem, as I noted, is that new packages are tested and built only with very recent versions of their dependencies. So, in order to try out a cool new program or to get an updated version of a program I use which has bug fixes or new features, I must also get new versions of all the dependencies.

And worse than that, these new versions simply aren't made available in binary forms for releases that are just a year old in many cases. Debian, for example, as stable, testing and unstable. But in reality, unless you want no ability to install new software, you have to run unstable. Now unstable is not nearly so unstable as the name suggests -- but this is still stupid. The truth is these new software packages you want to run don't really depend on all these new libraries and tools, that's just what the guy who built the DEB or RPM file had on his system at the time.

Running a stable system with older, more tested base packages is not an invalid goal. But it shouldn't prohibit you from running new software that doesn't actually and truly need something more modern.

Again, compare it to the Windows user running 7 year old Windows 2000 and having done one update to SP2. They can download and install almost every piece of Windows software out there. Try to run a 3 year old linux and you can't even get close to that.

Solutions...

Michael Kohne — Sat, 09 Dec 2006 13:00:38 -0800

Anonymous: The problem isn't just the packages that are distributed. Yes, regular updates to all the packages keeps the distribution up to date, but then you have touch broken configs regularly.

I believe there are two major points that Brad is trying to solve:
1) Configuration. Some packages can only be configured by modifying the config file that comes with the package. When you install a new version of the package, your config can be lost. This is broken, and I think the very simple solution of not making the user put their changes into the distribution config file is probably the best possible first to finally fixing this.

2) Dependancy. Not every package in the world is distributed through a package manager or has proper dependancies. Especially with software that one compiles oneself, the package manager is usually out of the loop, and thus, I can easily find myself with important software that 'suddenly' is broken. As Brad has noted, this is a MAJOR pain in the posterior, and doesn't do anything to help the image of Linux, or to get us away from dependancy on M$.

One thing I'm curious about: What do the Linspire folks do? Do they simply assume that you won't run anything that didn't come from them? Since all the packages would come through them, that would at least make it theoretically possible for all the packages to be correct. Do they have a real solution for config files?

Brad, thanks for getting a conversation going on this topic. I'm not currently using Linux daily, in part because maintaining the damn thing became more effort that it was worth to me.

Apt/Yum?

Anonymous — Sat, 09 Dec 2006 07:37:27 -0800

Neither apt nor yum (depending on whether your maintenance architecture uses .deb or .rpm files) suffers from dependency problems.

A given repository may not show a complete set of updates at a given time, which will cause either tool to reject the updates as incomplete (missing dependencies). This is not a problem - it's the correct decision! Once the repositories show a stable complete set of updates, they will be applied.

I've been running regular maintenance on many systems for many years, and have not experienced a problem. Understanding why maintenance updates are being rejected is the key.

There are some tools that can make incremental updates easier. for example, for yum there are a set of plugins:

yum install yum-fastestmirror yum-skip-broken yum-utils

You can then add the option '--ignore-broken' to your yum commands, and yum will try to apply as many dependency complete updates as possible (instead of giving up when encountering a missing dependency).

You can also periodically run:

package-cleanup --oldkernels --count=3

This will keep the latest three kernels, cleaning up the old ones (and dependent packages).

In short, the key to using apt or yum is regularly scheduled maintenance, and proper use of the included toolset. This causes small, incremental and easily managed changes to be applied to the systems. Trying to apply huge changesets, like a service pak, is where you will run into grief (and major system impact).

Kernel drivers

brad — Wed, 06 Dec 2006 12:36:54 -0800

I think making custom kernels is still considered a wizard thing in Linux. There are some automatic tools for certain drivers that will do all the work for you.

But even if the package is smart enough to compile with the headers of your current kernel, you need it against all kernels you run, and you need it to know that if I upgrade my kernel, I need to recompile all the special drivers for the new kernel -- which is a risky step because they probably have not been tested against that kernel, and the whole idea of a binary package is you're getting something that's been built and tested at least minimally against what it depends on.

I don't know what the plans are for the 2.8 linux kernel but a more modular driver architecture would be nice.

One aspect that I appreciate

Paul O — Wed, 06 Dec 2006 03:56:10 -0800

One aspect that I appreciate (at least theoretically; I run Debian Sid) about Ubuntu (and its K- and Edu- sisters) is the completeness of the system install: most users don't want to choose between the XFree86 and X.Org, for example. Let the advanced users worry about specialized configurations, rather than leaving it up to everyone to make each choice. And newer machines have enough disk space that installing a "complete" set of libraries and system tools isn't an issue.

If we were further willing to "version" those libraries (i.e. in the file tree, not just within the libraries), we might be able to let applications compile against newer libraries without affecting which version of each particular library other applications used. (And tracking the reverse links could allow an eventual trimming of the library versions. I'd like to see improved support for such capabilities in the file system, but that might cause additional problems, especially in the near term.)

As for kernel upgrades, I have never understood why the "default" binary driver packages didn't simply do the compile and install within the installation script, rather than making me execute such a script manually, line by line - often needing to consult pieces of multiple diverse sources where a script could determine the environment automatically.

Not an OS War issue

brad — Mon, 04 Dec 2006 15:57:54 -0800

I am not sure people would switch to VMS to fix this, unless it did what they need to do. Or Windows for that matter.

This is something that Linux and most other systems have to improve. Sysadmin cost is the highest cost of any OS, and the fact that linux is free-as-in-beer is really a pretty minor part of the cost equation right now.

To my mind, unless you do want to do a lot of things yourself, you need to pick a popular distribution. There is strength in numbers in any OS. With a popular distro (Ubuntu/debian, Fedora, SuSE) what you're going to get is a large body of people who have been through your problems, and already solved it. That's in part of what people like about the package systems -- on a big, popular distro, if there is some software you want, it is more likely to be in the package system so somebody has done the work of configuring and testing it on your system.

But we can do better.

One reason why I don't use Linux

Anonymous — Mon, 04 Dec 2006 06:02:08 -0800

This is one of the SEVERAL reasons I would never use
Linux, but prefer VMS. (VMS is free for non-commercial use;
for commercial use, it does cost money, but a) you get what
you pay for and b) it more than pays for itself since one needs
far fewer people to keep it running.) I have NEVER had to do
a fresh install. OS upgrades or patches are out-of-the-box.
It just works. I'm even running the latest version of VMS on
hardware which is 15 years old, and of course an executable
produced 15 or 20 years ago will still run on the most modern
hardware, with any version of the OS.

I'm fortunate to have a VMS day job, but I also have VMS at home.
No need to worry about viruses! True, it's not a popular virus
target, but even if targeted it is difficult or impossible to
write a virus.

Some folks might have used VMS several years ago and think it
is somewhat old-fashioned. Actually, it is still being developed
and was recently ported to Itanium hardware.