Tag Archives: linux

Configuring SHA rounds for password in RHEL5/6

Posted on by
Reply

Due to NIH syndrome and Drepper being Drepper, the only remotely secure password hashing algorithm in RHEL5/6 is multi-rounds SHA512. The default is just salted SHA512 which sucks.

Also applies to CentOS, ScientificLinux, and other RHEL clones.

Anyway, to update the default setting, these files need updating:

  • /etc/login.defs: add new line SHA_CRYPT_MIN_ROUNDS 5000
  • /etc/pam.d/system-auth-ac: find line with `password    sufficient    pam_unix.so sha512` and append rounds=5000.

Note that the change to last file may or may not be persistent. I have no idea how to properly set it up.

Finally, run this command: authconfig --updateall.

If you’re using RHEL5, run authconfig --passalgo=sha512 --update first.

Basic Dovecot/Postfix in Ubuntu

Posted on by
2

Configuring mail system is annoying. There are quite a bit different components which must be configured to work together.

My main choice for mail system is dovecot/postfix. As I don’t really understand how all this thing goes, I may have missed or misunderstood some parts. Or most of them. Feel free to correct this post.

For starter, most of basic configurations for Postfix and Dovecot has already been done by Ubuntu (or Debian) default configuration which includes enabling IMAP and TLS.

LDA

LDA (or MDA) delivers received mails to correct user and location. I let dovecot handle this thing because it’s easier this way. In /etc/postfix/main.cf:

mailbox_command = /usr/lib/dovecot/dovecot-lda -f "$SENDER" -a "$RECIPIENT"

[ Source ]

And that’s about it.

Maildir

The Mailbox format. The alternatives are mbox (ancient, shouldn’t be used anymore, I believe), or dbox (Dovecot only), or some other formats (which I don’t really care about). So basically I go with Maildir.

/etc/dovecot/conf.d/10-mail.conf:

mail_location = maildir:~/Maildir

[ Source ]

SASL

The last one, Postfix authentication. I use Dovecot SASL because it’s easier.

/etc/postfix/main.cf:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

/etc/dovecot/conf.d/10-master.conf:

unix_listener /var/spool/postfix/private/auth {
  mode = 0666
}

[ Source ]

For Dovecot config, it’s usually already in there, one just uncomment it to enable.

Restart Dovecot and Postfix, and that’s it. As I mentioned before, Ubuntu has preconfigured many things which leaves me only few additional tasks to be done to enable simple mail system (with TLS, IMAP, and whatnot).

Protip: use Google Apps or Live Domain instead of managing your own mail server.

FreeBSD is Rolling Release (the ports)

Posted on by
4

Don’t get tricked by the “release” system. Apart of the base system, FreeBSD perfectly qualifies as rolling release. I guess it’s also why the binary package management sucked so badly. You won’t find how to upgrade certain packages using binary method in their Ports’ UPDATING page.

Here’s the example:

20120225:
  AFFECTS: users of archivers/libarchive
  AUTHOR: glewis@FreeBSD.org

  libarchive has been updated to version 3.0.3, with a shared library bump.
  This requires dependent ports to be rebuilt.

  # portmaster -r libarchive
  or
  # portupgrade -r archivers/libarchive

You would think the dependent packages got version bump to ensure their proper dependency – but they didn’t. Instead you had to recompile everything depending on it.

And then there’s another case:

20120220:
  AFFECTS: users of graphics/libungif
  AUTHOR: dinoex@FreeBSD.org

  libungif is obsolete, please deinstall it and rebuild all ports using
  it with graphics/giflib.

  # portmaster -o graphics/giflib graphics/libungif
  # portmaster -r giflib
  or
  # portupgrade -o graphics/giflib graphics/libungif
  # portupgrade -rf giflib

Of course, ArchLinux kind of managed to do it but that’s a purely binary rolling release Linux distro. The maintainer worked hard to ensure such kind of thing get handled properly by all their users which mostly use binary packages. FreeBSD on other hand tried to claim capable of both but it really isn’t (unless I missed something).

I’m intending to contact pkgng creator to ask his opinion about this but have yet to do it…

This pile of crap called OpenLDAP

Posted on by
1

In attempt to learn THE directory service called LDAP, I tried to setup OpenLDAP in Scientific Linux. The install went all right and slapd can be immediately started without much problem. Except that the config is one big mystery and there’s not even a rootpw defined by default. Being a complete newbie in LDAP thingy, I decided to build configuration and all from zero.

…except that it’s not actually trivial. Most examples/tutorials are for OpenLDAP prior to 2.4 which still uses slapd.conf which was obsoleted in favor of configuration in meta-format using LDAP’s ldif. Instead of one nice config, we have directories called cn=config etc inside slapd.d. Someone must’ve been into Linux too much (xxx.d – Linux users sure love “modularizing” their configs).

Anyway, the example in manual page of slapd-config doesn’t even work because the include syntax was wrong (should be file:///etc/… instead of /etc/…) and even after fixing that there still an error:

[root@charlotte openldap]# slapadd -F /etc/openldap/slapd.d -n 0 -l initman.ldif
str2entry: invalid value for attributeType olcSuffix #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12)
slapadd: could not parse entry (line=626)
_#################### 100.00% eta   none elapsed            none fast!
Closing DB...
[root@charlotte openldap]# slaptest
slaptest: bad configuration file!

The example from the guide also gives exact same error.

In short, I kind of given up and tried to follow the “Quick Start” from the very same guide. Instead of using slapd.d format, it still uses slapd.conf format despite it being a guide for 2.4. Seems like following a pattern, the config example also spit out error:

[root@charlotte openldap]# vi slapd.conf
[root@charlotte openldap]# slaptest
/etc/openldap/slapd.conf: line 2:  invalid DN 21 (Invalid syntax)
slaptest: bad configuration file!

So much for an example. Few attempts later at both methods, I gave up and wrote this post.

Compiling PuTTY for Windows

Posted on by
7

Because of one awesome bug inflicts eye-cancer when using Consolas font and deactivated “Bold text is a different colour”, I had to recompile PuTTY by hand (more like, by gcc). I initially tried to compile the PuTTYTray one but apparently they successfully mixed C and C++ code and completely broke the build procedure using mingw. Or I missed something obvious.

Anyway, I went back to vanilla PuTTY. As it turns out, compiling using latest mingw’s gcc isn’t a good idea since it removed -mno-cygwin option and therefore broken unless you do some magic edit. Thanks to that, I stopped bothering trying to compile it under Windows and used mingw-gcc for Linux (which is able to produce Windows binary). Here be the steps from beginning. Tested on Debian 6.

apt-get install mingw32 subversion perl
svn co svn://svn.tartarus.org/sgt/putty putty
cd putty
perl mkfiles.pl
cd windows
make VER="-DSNAPSHOT=$(date '+%Y-%m-%d') -DSVN_REV='$(svnversion)' -DMODIFIED" TOOLPATH=i586-mingw32msvc- -f Makefile.cyg putty.exe

Patch is done before make (duh) and the diff can be found here. If you’re lazy (like me) you can just download the build at my server (link at bottom). Should be virus-free but I guess you can notify me if you encounter one. Built everyday until it breaks.

  • exe: the program
  • sha512: hash of the program
  • zip: both program and its checksum

[ exe | sha512 | zip ]

ZFS on Desktop – Which OS?

Posted on by
14

I’ve been thinking about this lately, especially after seeing this:

[root@einhart ~]# pkg_version -vIL=>
binutils-2.21 < needs updating (index has 2.21.1)
bitstream-vera-1.10_4 < needs updating (index has 1.10_5)
chromium-12.0.742.112 < needs updating (index has 12.0.742.124)
droid-fonts-ttf-20100214_1 < needs updating (index has 20110324)
exiv2-0.21,1 < needs updating (index has 0.21.1,1)
gawk-3.1.8 < needs updating (index has 4.0.0)
gcc-4.6.2.20110701 < needs updating (index has 4.6.2.20110708)
gnutls-2.12.7_1 < needs updating (index has 2.12.7_2)
libidn-1.19 < needs updating (index has 1.22)
openjdk6-b22_6 < needs updating (index has b23)
p5-Net-DBus-0.33.6 < needs updating (index has 1.0.0)
p5-libwww-5.837 Fetching ‘/usr/ports/www/chromium’

To build Chromium, you should have around 1 GB of memory
and a fair amount of free diskspace (~ 1.5GB).

===> Vulnerability check disabled, database not found
===> License BSD LGPL21 MPL accepted by the user
===> Found saved configuration for chromium-12.0.742.112
=> chromium-courgette-redacted-12.0.742.124.tar.xz doesn’t seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://download.goodking.org/downloads/chromium-courgette-redacted-12.0.742.124.tar.xz
chromium-courgette-redacted-12.0.742.124.tar.x 0% of 114 MB 35 kBps^C

And did you notice that “you should have around 1 GB of memory and a fair amount of free diskspace”? Yeah, it does use that much memory to update a web browser. Something that takes few seconds on Windows and Fedora and few minutes on Ubuntu takes almost hours to do on FreeBSD. Downloading source notwithstanding, compiling it also takes long, long time.

If anything, this is why I hate FreeBSD. And you will mention use package except that there’s no H.264 video support and possible chance of conflicting package difference between my system and the buildbot. As much as I want to use binary packages, they come in unwanted forms:

* GNOME 2 pulls Samba4 for God knows why reason
* Some pacakges don’t have optimization enabled
* Mplayer doesn’t have VDPAU
* Some packages must be installed manually (Java, Opera)
* Portupgrade takes minutes to compute what to do (something which is done in seconds in Ubuntu)

As much as I can tolerate this shit, the very fact that VirtualBox under FreeBSD takes much more CPU certainly doesn’t help.

So, I guess I’ll try yet another OS. There are several options so here are overview of current choices.

FreeBSD
——-
Pros:

* Extremely simple
* Up to date packages
* Highly customizable
* Stable ZFS

Cons:

* Customization comes at cost: compile time
* No good virtualization option
* A package management that is comparable with slowpoke
* No flash (yes there’s linux flashplugin ports but it’s a joke)
* Awesomely slow video playback even optimized on Firefox

PC-BSD
——
Pros:

* Based on FreeBSD, has some of familiarity
* Binary packages that’s not too slow
* Stable ZFS

Cons:

* Also no good virtualization
* Epic size of packages (eg. [a hundred megabytes for Firefox](http://www.pbidir.com/bt/pbi/49/firefox))

OpenIndiana
———–
Pros:

* Stable, greatest ZFS
* Zones
* Good VirtualBox support
* Flash support

Cons:

* Complex
* Doesn’t survive trivial hardware change without Live CD/USB
* ACL
* Outdated packages
* Non-existent packages
* Manual compiling of `mplayer` is a must since the defaults on various repositories are crap
* Still beta
* Doesn’t recognize FreeBSD’s GPT (at least on `oi_148`)
* Ugly freetype2 (no support for subpixel hinting apart of manual compile)

Ubuntu Linux
————
Pros:

* Latest, greatest software
* Good software support
* Good virtualization

Cons:

* Unstable ZFS
* Linux

Note that I only include Ubuntu in Linux category since it’s the only OS having both working nvidia driver and precompiled ZFS module, saving me lots of headaches.