Setting up OpenFiler 2.3 for VMWare ESXi storage

so I'm looking to set up openfiler as a storage backend for VMWare ESXi, just wanted to include some notes here, since the examples I've found in the forums isn't what I wanted to set up (disk sizes were fairly small).

So, main thing to remember is that OpenFiler doesn't handle the automated partitioning of the hard drive you're installing it on.  Best info I've found on this (without purchasing the Manual) is on Greg Porter's Wiki.  He has much excellent info on Openfiler, and I would highly recommend reading through his info.  This list here is just intended to be a quick checklist of things that need to be done to get this set up.

really rough run-down:

1. Get disk set up in RAID 5 on Dell 2850 (or hardware of your choice), preferably in hardware RAID rather than software RAID.
2. Boot from Openfiler 2.3 install disk (x86_64 in this case.... what, you haven't downloaded it already? (=  )
3. Using Graphical install, manually partition the disk as follows:
       /boot : 100MB ext3, Fixed size, Force Primary
       / (root): 2048MB ext3, Fixed size, Force Primary
      swap : 2048MB swap, Fixed size, Force Primary
4. Finish install (time, root password, etc.)
5. update, update, update (I've had some issues with this from the webgui; however, per the last entry of this forum, using "conary updateall" from the command line worked just fine.)
6. see Greg Porter's Wiki about the iSCSI reboot issue to prevent your stores from vanishing from the network upon reboot.  Last thing you want is for your system to boot and your services to fail.

At this point, you should be able to log in to OpenFiler, configure your shares, and get rolling.

DRAC4 Password Reset

So, building out a system for my work, and need DRACs for Out-of-Band-Management.  Found some Dell Poweredge systems on ebay for cheap (2850's and 6850's) and tried to access the DRAC cards with the default login....

didn't work.  )=

Looking for information on the web has taken most of the last week, since Dell's docs don't make it clear where the tools you need are, and what needs to be installed for them to work.

Goal: have Out-Of-Band Management on a storage system (Dell 2850 running OpenFiler).

I'm eventually going to run Openfiler on this system, but have installed CentOS 5.5 x86_64 to be able to complete this reset


Someone else ran into the same problem (used Dell's tools on windows), and the command that eventually resolved this for them was RACADM.  (see forum here).

in following the link on that forum, the CD that installed was not the correct one (the CD they list is for the initial install, I was looking for something I could install on an existing system).

So, here's the route that I went (racadm tools on CEntOS/RHEL 5.X):
(for 2850, this has been used to reset a DRAC 4/I)

Get Dell's RACADM installed on the system (instructions here)

Now, you can reset the card and be on your merry way:
      racadm racresetcfg (resets the DRAC)
      watch -n 60 racadm getsysinfo (lets you know when the DRAC has finished the reset)
      racadm setniccfg -s <rac ip addr> <netmask> <gateway>

Open a browser, point it at http://<RAC ip addr>, accept the certificate, and log in with the dell DRAC default login of username: root, password: calvin

I should also mention that to get the DRAC reset, these commands need to be run locally on the system, not over the network (however, you can connect over the network after the reset has been performed).

Hopefully this will save some folks headaches related to getting into the DRAC cards they have.  Overall process should take about 30-60 mins.

Installing RACADM for Dell DRAC 4/I on RHEL/CEntOS

Had several places this has become useful.  Follow the steps below to get Dell's RACADM tools installed on a RHEL/CEntOS 5.x system

UPDATE(2011.06.25) - use the LIVE CD when doing this, and you don't have to install CEntOS to fix this (ie: fix a system that already has something installed on it).  See notes at the end for additional commands.

Install CEntOS5.x Server and Server GUI from CD/DVD

install firefox with yum:
       yum install firefox
download the Dell OpenManage Deployment Toolkit:
       wget http://ftp.us.dell.com/sysman/dtk_3.5_new_43_Linux.iso

create a directory, mount the iso there and cd to that directory:
      mkdir /mnt/dtk_3.5_new_43_Linux
      mount -o loop -t iso9660 /path/to/dtk_3.5_new_43_Linux.iso /mnt/dtk_3.5._new_43_Linux/

      cd /mnt/dtk_3.5_new_43_Linux/
from here, run the following command to install the racadm tools:
       yum --nogpgcheck localinstall RPMs/x86/smbios-utils-bin-2.2.26-3.1.el5.i386.rpm RPMs/noarch/srvadmin-omilcore-6.5.0-1.385.1.el5.noarch.rpm RPMs/x86/srvadmin-racsvc-6.5.0-1.154.1.el5.i386.rpm RPMs/x86/libsmbios-2.2.26-3.1.el5.i386.rpm RPMs/x86/srvadmin-racadm4-6.5.0-1.154.1.el5.i386.rpm

UPDATE(2011.06.25) -  run the following commands to reset the DRAC without installing the OS

service racsvc start
locate racadm (it's in /opt/dell/something/i/dont/remember)
/opt/dell/rest/of/path/racadm racresetcfg

even though this will scream that it can't access the card, the card should be reset when you reboot

Configuring Alfresco 3.4 for AD SSO

My apologies if this is a bit rough, but I wanted to get this out due to the intense interest related to Alfresco.  Also, I would highly recommend setting up Alfresco like this from the beginning if you can, since it allows you to manage login from one database (fewer passwords for your users to remember, fewer systems for you to manage).

Goal: configure Alfresco 3.4 Community Edition to authenticate users as follows:

Internal users use SSO through Active Directory
External users authenticate against Active Directory (non-SSO)
Account info is synchronized with Active Directory

This information is based on http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems

Also, I've done the standard install (everything) in the gui based installer available from Alfresco.org to a clean Centos 5.5 system

first, we have to update the authentication chain in alfresco-global.properties (see my previous post on this for location).  I added the following lines:

### Authentication Chain ###
authentication.chain=alfrescoNtlm1:alfrescoNtlm,passthru1:passthru,ldap1:ldap-ad
alfresco.authentication.authenticateCIFS=false
passthru.authentication.domain=<domain_name>
ldap-ad.authentication.active=false

remember, passthru.authentication.useLocalServer, passthru.authentication.domain and passthru.authentication.servers are mutually exclusive, so only enable one of them.


Multiple Auth Servers of the same type
---------------------------------------
If I was using two different servers with the same authentication type (ie: two different ldap servers; not possible with passthru!), we need to copy the .properties files from:
/opt/alfresco-3.4.c/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/Authentication/<auth_type>/<auth_type>.properties

to
/opt/alfresco-3.4.c/tomcat/shared/classes/alfresco/extension/subsystems/Authentication/<auth_type>/<auth_type_instance#>/<auth_type>.properties

you will need to create the directory tree below the extension subdiretory, starting with subsystems.  Remember, this is only required if you have two auth servers using the same auth type.  Check the Alfresco wiki if you aren't sure.
---------------------------------------


in looking at the ntlm-filter.properties files in the passthru and ldap-ad folders, I found that the settings of these systems was already configured for passthru to have SSO enabled.  Also, I found that if you have passthru and alfrescoNtlm set up, after an unsuccessful SSO login, the "backdoor" URL (http://<hostname_or_IP>:8080/alfresco/faces/jsp/login.jsp) will automatically display (at least in Firefox).  So this is actually as expected, since it fails through to the local login.  Don't know how this would look to the outside world, since I'm mainly using this on a company intranet right now.

So, to recap; after doing everything above, this is where I'm at:

Goal: configure Alfresco 3.4 Community Edition to authenticate users as follows:

Internal users use SSO through Active Directory - this is completed and working fine
External users authenticate against Active Directory (non-SSO) - this is completed as far as I can tell
Account info is synchronized with Active Directory - this isn't working right now, so I've missed some settings for this authentication type.  I suspect I may not have the OU/CN/DC settings correct for what AD wants to see.