Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Monday, June 21, 2010

NT_STATUS_PIPE_DISCONNECTED with Samba Winbind and Windows Server 2008 R2 Domain Controller

We recently upgraded our domain controllers to Windows Server 2008 R2, and our RHEL 5 authentication through our Windows domain immediately broke.
Here was the error:
[2010/06/21 09:32:57, 0] rpc_client/cli_pipe.c:rpc_api_pipe(790) rpc_api_pipe: Remote machine adserver.my.edu pipe \NETLOGON fnum 0x8007returned critical error. Error was NT_STATUS_PIPE_DISCONNECTED
A little searching online shows a lot of people with this or related problems, but the solutions appear to be many, and there mostly isn’t a solution posited.
But there is this: https://bugzilla.redhat.com/show_bug.cgi?id=561325
In short: there's a bug in the samba package that prevents it from working with Windows Server 2008 R2 domains. If you’re running into this problem, the solution is to remove your existing samba installation and install, instead, the samba3x packages.
Note that samba3x was a "technology preview" from RedHat, which means that it offered little support for it. This has changed, and it's now a supported package in RHEL 5.
yum erase samba samba-common
yum install samba3x samba3x-client
You’ll have to re-do your configuration, so it might be worthwhile to back up your /etc/samba/smb.conf file.

Monday, July 27, 2009

Installing Oracle on RHEL 5 (32 and 64 bit) - Part 3

In part one of this series, we got the operating system ready for the installation of Oracle. In part two, we got Oracle installed and running. In this, our final (for now) post on Oracle and Linux, we'll look at some of the tweaks that make it better, as well as some of the surprising bumps one encounters when using Oracle on Linux.

Sunday, July 26, 2009

Installing Oracle on RHEL 5 (32 and 64 bit) - Part 2

In part one of this series, we got the operating system ready for the installation of Oracle. In this post, we'll actually install Oracle and get it up and running. In part three, we'll look at some of the things you can do to make Oracle a bit more usable on the Linux platform. Oracle recommends using the GUI installer. I think they're right: it's the most accessible way to get Oracle installed. If you only have remote access to your system, and SSH is the only remote access you've got, you can set up VNC reasonably quickly to have remote GUI access to your system.

Thursday, July 23, 2009

Installing Oracle on RHEL 5 (32 and 64 bit) - Part 1

With the then-hyped Oracle Enterprise Linux rollout, and Ellison's evident disdain for Microsoft, you'd have thought that Oracle would go out of their way to make it straightforward to install and use Oracle database on Linux. It's not so, unfortunately. Not that it can't--or shouldn't--be done, mind you: it works great; you just need some persistence. This is part one of a three-part series on Oracle on Linux. This post looks at getting the OS ready for Oracle. Part 2 looks at installing the database software, and Part 3 talks about some of the things that can be done to make running and maintaining Oracle easier on Linux. Oracle has a document here that does a pretty good job of outlining the steps necessary to install Oracle on linux. I quibble with some of their instructions, particularly their directions to use the package rpms from the Oracle install CD. If they're going to go to the trouble of providing the requisite rpms, it seems like they'd also install them during the installation process, if they're needed. Instead, it seems like a *much* better option to install them from your repository (CENTOS or RedHat are most pertinent to this guide). They also have you using rpm, which is fine, but it won't find dependencies for you like yum will. In any case, I do recommend that document for additional information. It's my hope that this series will help navigate the installation process and make it easier. I've broken this into several posts so as to keep the length of each one a little smaller, anyway. In this post, we'll get the OS prepped and ready for the

Friday, May 15, 2009

Converting a Physical Linux system to a VMWare VirtualCenter VM

This is a daunting task. At least, it is until you figure out how to do it. Once you've got the steps, it's quite simple, and relatively quick. We'll be importing a physical Linux (CENTOS 5) server -- using IDE drives -- into a VMWare VirtualCenter-managed host. So immediately, one thing needs to be made clear: the tools we're using in this exercise aren't free. There are a variety of tools out there that are free, and I may get around to exploring those for this situation, as well. In the mean time, however, we're talking about VMWare Enterprise Converter 4 (v3 works, as well), which isn't available (yet, anyway) without cost. So enough of the fine print: let's get to it.

Tuesday, March 10, 2009

Active Directory (AD) Authentication on a Linux Server

Domain Authentication for Linux

I've updated the instructions here to support RHEL 6. I've streamlined things a bit, too, so I'd head over to this page to get the latest on setting up AD authentication for a Linux server. There are a lot of how-tos surrounding the integration of authentication and authorization in Linux through Active Directory domains. I've found a variety of them helpful, and I've found more to be confusing, rather than helpful. Here I'm hoping to put together a start-to-finish process for using your domain to authenticate and authorize users on your linux box. These instructions are written for Red Hat Enterprise Linux v5 (RHEL from now on). That means the file locations should be the same for CENTOS distros (which I highly recommend as a server OS), but that they might move around a bit for others.

A very small bit of background: this system uses winbind and smb to connect to the domain to authenticate users. Kerberos is used to join the system to the domain. The benefit of this system is that it's secure and it's pretty easy to configure. Coupled with PAM (Pluggable Authentication Modules), it's quite flexible, and it's really pretty cool functionality.

Friday, February 6, 2009

Setting up a VNC remote desktop in Enterprise Linux 4, 5, and 6

This is something that is terribly useful, and there are lots of how-to articles running around. Unfortunately, I've not found one that was quite complete, especially for someone who is only just getting familiar with Linux (which is precisely when you most need a GUI!). So this is a step-by-step instruction list on getting a remote X Windows session set up on enterprise linux 4, 5, and 6 (RHEL and CENTOS) that can be accessed with VNC viewer software (do a quick search on VNC if you're not familiar with it). In some set-ups, people create a VNCSERVER process that runs all the time. This does allow for persistent sessions (sessions that survive a disconnect), but it's not really what most of us need most of the time. What we're doing here is using xinetd, which will spin up Xvnc on an as-needed basis. Much cooler. Please note: vnc is not a secure protocol. What this means is that any traffic that VNC sends over the wire is *not* encrypted. Do make sure that your use of this doesn't put you at risk for having sensitive data (passwords, for instance) compromised.

Sunday, March 16, 2008

Rebuilding RPMs in RHEL

How to rebuild a RPM from source Reconfiguring and rebuilding RPMs can be immensely useful, particularly when, as in the case of AMANDA backup software, you need to make a change that is used over and over again on a lot of clients. The steps are pretty straightforward. In short: To tweak an existing package
rpm -i .src.rpm
This puts all sources into /usr/src/redhat/SOURCES/ and the .spec file into /usr/src/redhat/SPECS/ which you can change as required To change the compile settings Edit the /usr/src/redhat/SPECS/.spec file to meet your needs To build the binary Then run the following command to build the RPM:
rpm -bs /usr/src/redhat/SPECS/.spec
rebuilds the RPM from the modified source. -- How to rebuild the AMANDA source to create new install RPMs This is an important thing to do: AMANDA by default picks random high tcp ports on which to communicate with the clients. This is a problem when we cross subnets, in particular, since the firewall needs to know which ports are needed. So we recompile the source to include the --withtcpportrange= and --withudpportrange= switches. This will limit AMANDA to the appropriate port ranges. This is from http://wiki.centos.org/HowTos/AmandaBackups 1. Download the amanda-xxxxx.src.rpm file. 2. Install the source rpm: rpm -i amanda-2xxxxx.src.rpm. This will extract the contents into your rpm directory (if you're doing it as root, it'll be /usr/src/redhat/.) 3. Edit the SPECS/amanda.spec file to reflect the appropriate changes. It's a good idea to changed the Release: tag to indicate you've made changes. In addition to just helping you keep track of what you've changed from the default, this will help keep the package from being updated automatically when you patch the system. To set up AMANDA to use specific ports that we can open up on the firewall, we want to add the following to the ./configure command. Don't forget to put the trailing back-slashes at the end of the lines.
--with-tcpportrange=50000,50100 \ --with-udpportrange=700,710
4. Rebuild the rpms:
rpmbuild -bb --define "build_rhel5 1" /amanda.spec
or for RHEL4,
rpmbuild -bb --define "build_rhel4 1" /amanda.spec

Saturday, March 15, 2008

Using 'Alternatives' in Linux to use a different Java package

Installing Sun Java alongside the default GNU java using the 'alternatives' system.
This post shows how to install Sun's java implementation alongside the Linux default GNU java.

Installing Sun Java alongside the default GNU java

Sun's java isn't installed by default on RedHat systems. This is because Sun hasn't licensed it for RedHat's distribution. Instead, Linux ships with an open source alternative, GNU Java. It's based on Sun's Java implementation, and--in part because of that--it's always a version or two behind Sun. In all, it's a very good implementation, but sometimes--as in the case with DSpace--it's necessary to use Sun's Java, instead.
We don't want to remove the Gnu Java; we'll install Sun's alongside it.