iPXE with Serial Console

My SmartOS based home server is already configured to use the serial console, in case I need to physically plug into it, but there was a missing piece. iPXE, the boot loader I use to boot the smartos image, can use the serial console, but this is not the default. I couldn’t find an existing binary that was configured with serial, so I built it myself.

Its pretty easy to git clone their repo, un-comment a line, and build the binary, but I wanted an automatic way to do so. I’ve seen Travis-CI around and one of its features is being able to build artifacts and post them to your repo as a release. I created a git repo, ipxe_serial, for this project.

Once you have your GitHub account linked with Travis, you’ll enable it for a repo, though you’ll probably want to change the settings to only build if the config file exists, .travis.yml. Travis has a cli client that you’ll need as it makes setting up the GitHub Releases integration easy. Install the client and authorize it to use your GitHub account, then from within your repo directory, use travis setup releases and follow the prompts. It writes to your travis config file and creates a GitHub token for your repo and encrypts the token before putting it in the config file.

Afterwards, I think its a good idea to have the following added:

deploy:
  skip_cleanup: true
  ...
  on:
    tags: true

From reading the docs, this looks like a good thing to have. With that, I can then tag a commit and Travis will run my build script and create a release on my repo.

Advertisements

Building exabayes(1.2.1) for Rocks 6.1

To build exabayes(note, this is for version 1.2.1. 1.3 just came out and doesn’t build for me just yet) on Rocks 6.1, which is based on CentOS 6.3, LLVM’s clang and libc++ need to be installed. I have a previous blog post about this.

The available prebuilt binaries do not work on CentOS 6.3, but once clang and libc++ is installed, rebuilding it is fairly straight forward. Download and extract exabayes and go into its directory. Use the following commands to configure and build both the serial and parallel versions of exabayes:

CC=clang CXX=clang++ CXXFLAGS=”-std=c++11 -stdlib=libc++” ./configure
make
OMPI_CC=clang OMPI_CXX=clang++ OMPI_CXXFLAGS=”-std=c++11 -stdlib=libc++” CC=mpicc CXX=mpic++ ./configure –enable-mpi
make clean
OMPI_CC=clang OMPI_CXX=clang++ OMPI_CXXFLAGS=”-std=c++11 -stdlib=libc++” CC=mpicc CXX=mpic++ make

mpicc and mpic++ are just wrappers for gcc, but by using those environment variables, they can be pointed to another compiler without having to build a separate version of openmpi. Now that is done, within the top level directory are all the exabayes binaries. Ignore the ones in bin/bin, those are the prebuilt ones that don’t work.

Building libc++ on CentOS 6

For the cluster I manage, a user needed exabayes(there will be another post on building that later) but their prebuild binaries didn’t work on Rocks 6.1, which is based on CentOS 6.3. GCC is too old to build it as they use C++11, but luckily clang 3.4 is available from EPEL. Only thing, it still wouldn’t compile. I got the following two errors:

/usr/bin/../lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/exception_ptr.h:143:13: error:
unknown type name ‘type_info’
const type_info*
./src/Density.cpp:79:34: error: use of undeclared identifier ‘begin’
double sum = std::accumulate(begin(values), end(values), 0. );

While there was a potential workaround for the first error, nothing viable was to be found for dealing with the second error. But this research pointed in the next direction, building LLVM’s libc++ as these errors have to do with GCC’s old version of the standard c++ library. Its a bit complicated and rather hackish but looks like it works, so here we go.

Download libc++ via svn, but instead of following their directions for building, do this:

cd libcxx/lib
./buildit

Thanks to this blog post, which is in Chinese, but the commands are easy to understand. After building the library, copy it to /usr/lib(or because this is 64bit, I put it in /usr/lib64) and create the needed symlinks. Then copy libcxx/include to /usr/include/c++/v1. Remember this as we’ll be replacing libc++ later with a rebuild version.

Next is building libc++abi. Again download from svn and build it like above and copy the library to /usr/lib64 and make the symlinks. The include directory doesn’t need to be copied. Now time to rebuild libc++ with libc++abi. This requires CMake, and I opted for the newer version available from EPEL. The command is then cmake28. I also started with a fresh download of libc++

cd libcxx
mkdir build
cd build
CC=clang CXX=clang++ cmake28 -G “Unix Makefiles” -DLIBCXX_CXX_ABI=libcxxabi -DLIBCXX_LIBCXXABI_INCLUDE_PATHS=”<libc++abi-source-dir>/include” -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr ../
make

Since I don’t like to mess with the system install, I used DESTDIR during the make install step. This then allows me to build an rpm package using rocks create package. I also create a package for libc++abi.

With this now its possible to compile with clang and c++11. Test it out like so: clang++ -stdlib=libc++ -std=c++11 input.cpp

Setting up LAM Pro with SELinux

Been a while since I had to install LAM Pro and now that I have the new version, I ran into a couple of issues. First there is SELinux, which has saved my butt a couple of times, so I work to always have it enabled. I cringe whenever I see the first step in someone’s howto is to disable it. Its complicated and I do not profess to be anywhere near an expert in it, but I get by. Second is to secure the install, and while SELinux helps in that regard, there are still steps to take.

Installing:

LAM Pro is the paid version of LAM, LDAP Account Manager. Starting with a fresh install of CentOS 6.4, I downloaded the LAM Pro source and use its install script:

# ./configure --with-httpd-user=apache \
              --with-httpd-group=apache \
              --with-web-root=/var/www/html/lam
# make install

By default it will install everything into /usr/local/lam and use httpd as user/group name. Here I fix that to use the CentOS default of apache as user/group. Also it’s recommend to separate the web interface from the more sensitive parts, like the config files and session information.

SELinux Configuration:

If you were to start up a browser to load up LAM, even with SELinux disabled, there is the issue of writing config files. They are stored in /usr/local/lam/etc, where the web server doesn’t have permission. Also there is the session and tmp directory in var it uses to cache data from ldap. So use chmod to fix that:

# chmod -R apache:apache /usr/local/lam/etc
# chmod -R apache:apache /usr/local/lam/var/sess
# chmod -R apache:apache /usr/local/lam/var/tmp

But with SELinux enabled, apache still doesn’t have permissions to write outside of its own root directory. We need to tell the system the right context to use to allow apache access.

# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/var(/.*)?"
# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/etc(/.*)?"

Next is to apply these settings to the files themselves:

# restorecon -R /usr/local/lam/var
# restorecon -R /usr/local/lam/etc

Now apache can run LAM with SELinux enable and not run into any issues.

Apache Configuration:

The next part is to secure the installation. LAM comes with htaccess files ready to use to protect the config files and other sensitive files. Its my preference and you can do it differently, but I start with creating /etc/httpd/conf.d/lam.conf to hold these directives.

<Directory /var/www/html/lam>
   AllowOverride All
</Directory>

Now you could just change the server wide setting in httpd.conf, but I like to follow the principle of least privilege.

Next would be to set it up to use SSL to keep prying eyes from grabbing your passwords and user information, but that’s a whole other topic.

CentOS: Eclipse and PyDev

I’ve usually just used a simple text editor like nano when writing python here and there, but I do like the visual aspect that a good IDE provides and though I’d give Eclipse + PyDev a try. Used yum to install eclipse and then added PyDev’s repo to eclipse to only then run into a problem when I tried to install PyDev. I got this long list of  “No repository found containing” messages. Searching the issue I did not find any useful answers as they were the usual, “Just start fresh,” or, “Don’t use the distribution version, always download from the web site,” kind of messages. Not helpful at all.

Luckily I found the following bug post and discovered the issue was with a missing package. Not really sure why it isn’t just installed be default but what is needed is the eclipse-pde package. That’s plugin development environment that is apparently needed to install other plugins, like PyDev. Once that was installed, I got PyDev installed and now I’m ready to go forth.

Roaming Profiles in Samba

I run primarily Linux but I do have a Windows server for those who need a bigger Windows machine to work on and make it available via remote desktop. To have it play nicely with the rest of our systems, I also run a domain via Samba. While I don’t like roaming profiles, my users are used to it and the messages about unable to load a profile bother them.

Recently a user needed access to the Window server but then had weird access denied errors when trying to logon. I had them in the remote desktop group and the only messages in the logs were with loading errors about the profile.

The error shown was “Group Policy Client Service Failed The Logon.” Searching show this was a symptom of a corrupted profile and thus I deleted it, but then after that it was never regenerated and thus the missing profile messages every time since. 

Thanks to a guy named Steve on the mailing list, I was able to determine what was going wrong. Within the registry, Windows stores some info about the profile, in particular is the location on the server. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowNT\CurrentVersion\ProfileList stores a list of user SIDs and they key CentralProfile was wrong. Deleting the entry from ProfileList fixed the profile errors and now its all good.

[Samba] Windows Profiles Not Being Created

Apache, SELinux, WebDAV, and cgi-bin

I had setup webdav access for a user to allow them the ability to upload and edit their web application and as part of that setup, they had their own cgi-bin. Not normally an issue, but as a way to prevent any security issues, I’ve kept SELinux enabled. Turns out this was causing a problem with uploading files into the cgi-bin directory. Sadly there wasn’t an easy boolean value I could set for this but the audit2allow command came in handy.

Now be sure you check the module code before enabling it to ensure nothing shady is there. Simply running audit2allow on all messages in the audit log would build a module that can include permissions to allow potential hacks through. I saw some weird permissions that I knew were not needed to allow webdav access to cgi-bin and removed them from the module file. Here is the module that finally allowed access to the cgi-bin directory:

module webdav-cgi-bin 1.0;

require {
type httpd_t;
type httpd_sys_script_t;
type httpd_sys_script_exec_t;
type httpd_sys_rw_content_t;
class dir { write remove_name create add_name };
class file { write create unlink execute setattr};
}

#============= httpd_sys_script_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_sys_script_t httpd_sys_rw_content_t:file execute;

#============= httpd_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_script_exec_t:dir { write remove_name create add_name };

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_script_exec_t:file { write create unlink setattr };

Now this allows the web server read/write access to cgi-bin, which might be an issue, but I do protect webdav access behind access controls and SSL.

OpenSSL: Request Certificate Distinguished Name Mismatch Solved

I’m not sure if its a bug or a feature but something I ran into when signing a certificate request with our self signed certificate authority. The new system is running CentOS 6 and when I tried to sign the request, it would fail saying the state name didn’t match. It prints them both out and as far as I can tell, they are the same. But something that bothered me gave me a clue. It would print out Distinguished Name like so:

stateOrProvinceName :ASN.1 12:’Texas’

That ASN part made me think and this bug post gave me an idea. As I didnt want to go playing with the policy setting, I read through the openssl.cnf file for more details and I came upon the string_match setting. My CA had been created using the nombstr setting while in CentOS 6, it was set to utf8only. Editing openssl.cnf on the new system and creating a new request fixed the problem and now the DN looks like so:

stateOrProvinceName   :PRINTABLE:’Texas’

So just be aware of this setting

Weird smpatch Security Error(Solved)

So today I did my first live upgrade of a solaris system. Takes a while but is rather easy with ZFS as the root file system. Anyways, now that I’m running the latest release of Solaris 10(8/11), I want to then make sure all the patches are then installed. Run smpatch analyze and I get the following(taken from /var/adm/messages):

Oct 24 16:51:41 ****** root: [ID 702911 user.error]  => com.sun.patchpro.util.Ca
chingDownloader@1e12f6d <=Downloader.getResponseCode() : IOExceptionsun.security
.validator.ValidatorException: PKIX path building failed: sun.security.provider.
certpath.SunCertPathBuilderException: unable to find valid certification path to
requested target

Looks scary but it lists all the new patches needed. I then try smpatch download only to get the same error followed by it saying the patch was unavailable for every single one. Not good. Looking around and from what I can read into this error, I think its has to do with the certificates used to connect to the Oracle update servers. I look through the patch list and find Update Connection System Client listed. I manually download that patch(121118-20) and install.

Ta Da! Fixed and smpatch is now happily downloading the latest patches. Now back to work.