- OES2 SP2 Installation
- SLES 10/OES2 Multi-pathing
- Configuring NSS
- DHCP Installation
- Post Installation Steps
- Setup NRM
Please keep in mind this is not the only method or set of guides that can be used. Each environment is unique and different. Our setup consists of three different sets of servers. We have non-clustered NetWare servers on HP BL460c blades. We have a 16-node NCS NetWare Cluster on the same type of blades. Lastly, we have about 35 servers (HP DL385) in our regional offices. As such, each server type required a slightly different approach.
We found that because we have a large number of home directories and ZEN NAL app objects, as well as an IDM environment in use that all of our migrations would be done using the ID Transfer scenario. The exception to this is our NCS Cluster (which has not been done yet). Because the majority of our regional servers also have GroupWise on them, we figured it would be quicker to just migrate all the services, and then do an ID Transfer. As such, this is a variation on a theme.
As always, TEST, and TEST some more. Use whatever method works best for you, preferably one that is supported.
I’ve tried to remove all server names, IP addresses, and incriminating evidence.
Lastly, read the product documentation as there are some pre-requisites (ie, make sure eDir is healthy, a specific eDir version, backups, etc.) you need to make sure you have met.
Before you even attempt to install OES2, you must make a few decisions:
- 32-bit or 64-bit. Normally there is no technical reason to use 64-bit unless you have memory requirements that dictate it. However, Novell has decided recently to only support 64-bit on some of their products. As such, please make sure you investigate all your third party applications to verify any 64-bit compatibility issues with SLES and OES2. There is NO such thing as an in-place upgrade from 32-bit to 64-bit. If you have already deployed 32-bit OES2 and use GroupWise you will be forced to setup another server, install OES2 64-bit on it and do yet, another migration in order to run the next versions of GroupWise. (8.0.x will still be 32-bit, but all future versions will be 64-bit only).
- Do you want to use DSFW (Domain Services for Windows)? You can ONLY install DFSW during the initial install of OES2. It CANNOT be added on later (unless you setup yet another server). Decide now unless you have spare hardware or VM’s to use.
- Will this be a pre-migration server (used for ID Transfers) or not? During the install, you can check “pre-migration” pattern. This will not put a replica on the server.
- If you are going to use NSS or WANT to use NSS, you MUST partition your disks properly BEFORE you install. You do NOT want to have one large “drive/LUN/logical drive” to install everything onto. Bad things will happen. At a minimum, you want TWO disks/LUN’s/Logical drives. One for your SLES “boot/root, etc” stuff and another for your NSS stuff. (You can have more if you want). It’s up to you to use whatever native drive utilities to carve out the LUNs (ie, DL360/380x with HP RAID you can use the ACU or something to create two or more logical drives).
- SLP DA. In OES2 there is no more SLP DA. Instead it’s OpenSLP. There are some issues (IMO) with OpenSLP. The first item we ran into was a compatibility issue with using OpenSLP as a DA on OES2 AND also using an SLPDA on NetWare. This was fixed with an SLP patch for SLES. Secondly, the major issue is if you have to restart OpenSLP on OES2, it can take hours for it to rebuild the SLP information. And if your clients are pointing to that DA, they’ll probably give errors about not being able to contact various resources. There are some cool solutions that discuss how to manually create a static file with all your servers (a bit time consuming, but better than having thousands of users not being able to login and attach to resources). Supposedly in OES2 SP3, Novell will introduce some form of caching with OpenSLP as a DA so that this issue is addressed. Your choice can either be to use OpenSLP and live with (or workaround) the caching issue, or put another DA on NetWare and keep it around until SP3 is out.
In this example, I am installing OES2 SP2 64-bit on an HP BL460c blade with multipathing onto a Xiotech Magnitude 3000 SAN.
First, if this is a dual-SAN connected server, make sure to disconnect the secondary path and only run the setup with the first connection.
There are many ways to install OES2. We find it faster to install from the network, after we boot from the SLES 10 SP3 DVD. However, you can also use the local DVD/CD drive, or for the blade servers, use the HP ILO to accomplish the same thing (although ILO is limited to 100MB connection, so it’s usually faster to boot from the virtual DVD, and pull the install DVD/CD info from the Linux server we setup as an install source). If you are using the CD/DVD method, please use the SLES 10 SP3 DVD media (to avoid CD swapping). The OES install is only on CD.
If using the media, boot from the SLES 10 SP3 media, select Installation and hit Enter. Then you can skip to page 3. Currently we are only using OES2 SP2 64-bit codebase.
On page 8, you would modify the instructions so that you select CD for the OES2 SP2 CD media (if using the local CD/DVD drive or HP ILO virtual media).
Alternative boot method:
- Boot from SLES 10 SP3 media
- Select Installation, but don’t hit Enter
- At the bottom enter the options: install=nfs://slesadmin.abc.com/install/path hostip=IP netmask=mask gateway=192.168.x.x nameserver=192.168.10.10
- Paths are:
Ie: install=nfs://slesadmin.abc.com/install/SLES10SP3_32/CD1 hostip=192.168.10.9 netmask=255.255.255.0 gateway=192.168.1.1 nameserver=192.168.10.10
Check the “include add-on products” and click Next
Then click Next.
Click OK. Be careful here to make sure the “bit” of OES2 matches the “bit” of your SLES (ie, 32-bit SLES and 32-bit OES2 or 64-bit SLES and 64-bit OES2). You do not want to mix the two.
Click Yes, and then Next.
Set the “Hardware Clock Set To” to Local Time (this means you’re telling it what the CMOS clock is set to, and on the HP Blades, it’s ALWAYS local time). Make sure USA and Eastern are set as well and click Next. Later we’ll configure for NTP time.
(I forgot to screenshot the above screen for OES2 SP2 64-bit, so it shows SP1).
Click Partitioning (we need to change some stuff).
Click “Create Custom Partition Setup” and then click Next (what you see on the next screen may vary depending on if this is a dual-pathed Blade or the standalone regional servers). Your environment may vary and you may wish to use LVM. We chose to use “native partitions”.
Why do we do this? We don’t like to setup one big LUN (virtual disk, logical drive, whatever your RAID hardware calls it) for / (root partition) using Reiserfs.
With OES2, you ALWAYS want to setup a dedicated LUN for your “boot” code, and leave a separate LUN for NSS (if using NSS). NEVER allocate all your disk space to one LUN. Think of this as NetWare, in the sense that you had your DOS partition separate from NetWare partitions, and SYS volume separate from your other volumes.
Select Custom Partitioning and then click Next.
We have two LUNs here. A “boot” LUN (the 15.0 GB LUN) and a secondary LUN for NSS volumes. We are only going to setup the boot LUN for now.
Select 1: /dev/sda and click OK. (the naming will change depending upon your hardware)
Select Primary Partition and click OK
Make sure to set the file system to Ext3 and the size to 1.0 GB and the mount to /boot
Choose 1: /dev/sda and click OK
Choose Primary Partition and click OK
Change “file system” to Swap.
Set to +2GB and click OK (don’t forget the mount point of swap)
Click Create and Primary Partition again.
Change file system to Ext3 and let it use the rest of the LUN and mount point is /
Click Finish as I’m not sure what other partitions to make at this point. You can only have 4 Primary Partitions in Linux/OES (per disk/device/LUN).
We’re going to leave LUN #2 alone for now. This will be used later for NSS/EVMS volumes.
(again, forgot to screenshot the above for OES2 SP2 64-bit)
We always uncheck the Novell AppArmor. For OES it will depend upon what type of install you are doing. All our OES2 servers should have the following items selected:
- Novell eDirectory
- Novell Backup/SMS
- Novell iManager (you never know when you’ll need it on the server)
- Novell Storage Services (this should auto-check the Novell LUM, and Novell NCP, but I will list them here anyway)
- Novell Linux User Management (LUM)
- Novell NCP Server/Dynamic Storage Technology
Depending upon your server (new install vs. migration) you may also check the “Novell Pre-Migration Server). For a new server install (as opposed to one you are going to migrate with the ID Transfer) you would NOT check that box. We choose to install NSS even if we aren’t going to use it right away (again, never know when you may want/need it). I find the NCP server handy so that you can use native Linux EXT3 partitions and attach to them with Windows PC’s via the Novell Client (as opposed to having to muck around with SAMBA configurations). This also adds NCP file locking if using GroupWise and the ConsoleOne Windows Management snapins.
For an Identity Transfer operation (migration), make sure that you selected the Pre-Migration Server option.
Depending on the server you are transferring, you may have to select iPrint and DHCP, in addition to other items. Scroll down and make sure you selected NSS.
I also install the C/C++ Compiler tools because you never know when you may need them.
(Most notably on Vmware, or if using the HP Proliant Support Pack–because it installs non-kernel drivers sometimes and therefore you need the Compiler to recompile the kernel for non-stock drivers).
Click Accept again.
Click Accept again.
Wait for it to create the partitions
It should reboot and launch the rest of the install
Enter in the password. This should be different than the eDirectory Admin password. Click Next.
Uncheck the “change hostname via DHCP”. We don’t give out DHCP in the server room. Follow your standard naming convention.
Identity Transfer/Migrations – Server Naming:
You must enter a TEMPORARY name here. I suggest a format of:
Temp-oldserver (ie: temp-main, temp-nw1, etc.)
Set firewall to disabled (for now).
Also Disable IPv6. I’ve had issues with it in the past.
Click Network Interfaces
On the Blade servers, the first HP NIC is usually the “primary” one. You must double-check by looking at ILO for the MAC address and comparing to what SLES shows.
Sometimes Linux assigns the NIC in reverse order (ie, 2nd NIC will be eth0, 1st NIC will be eth1). Make sure to find the MAC address of the NIC and compare against what Linux finds (click Edit and you can go to the Advanced section and verify the hardware address). Otherwise you may THINK that first NIC listed is the primary NIC (eth0) and it’s not. Then your install fails later because of this. Alternatively you can disable the secondary NIC in the BIOS and re-enable it later. (We have had problems with the DL385 HP servers where disabling the 2nd onboard NIC also disables the on-board RAID controller for some odd reason).
Set the IP and Netmask.
Click Hostname and Name Server
FOR Identity Transfer/Migration:
You must use a TEMPORARY IP address. When the migration is finished, the temporary server name and IP will be removed automatically from the OES2 server.
Enter the appropriate DNS servers and click OK (double-check that hostname and domain are still correct).
Click the Routing button
Enter the default gateway and click OK (obviously the gateway can differ depending on where the server is installed).
I believe it puts the “configured” NIC on the top now, even though we hopefully configured the second one. Click Next.
Select the VNC Remote Administration so that it is enabled. We choose to use this so that we can use the NRM (Novell Remote Manager) VNC Consoles option. ILO will work as well, albeit slower (and the mouse cursor has issues until you install the HP drivers). Note: There may be an issue with this but we are still waiting for a response from Novell for our active SR with VNC causing high CPU utilization.
We may change the Proxy section later. (obviously if your environment requires this, you can enable it now or later—it’s up to you).
I usually skip the test.
DO NOT use LDAP with OES. OES uses it’s own LDAP server (eDirectory). You CANNOT use OpenLDAP and eDir at the same time.
For this, we’d install into the existing tree. Insert the proper tree name. (Assuming you are installing into an existing environment, vs. a brand new install).
I also uncheck the Require TLS for Simple Binds. It tends to cause issues if you don’t uncheck it. DSFW may require different options (we don’t use it here). I also believe SecretStore is optional as well (usually you’ll be told if they need to be installed or not).
Input whatever IP contains a replica of the partition you plan to install this server into. If you have a DS Master or R/W replica server, I suggest you use that.
Enter the admin userid in LDAP format (ie: cn=admin,o=something) and the password.
Please note there may be an issue here if you have funky/long passwords (passwords with “odd” characters in them).
Be careful here. Enter the server context in LDAP format (there’s no browse button, so you have to know where the server will be installed to). I leave everything else the same.
We may change the DIB location later, not sure yet. (It really depends upon how large your dib set is and if you want or have dedicated a mount point for /var).
For now, I pointed to our Unix server for time. Basically if you already have an NTP time source, point it to that. If you don’t, you can probably use one of the public ones out there. If this is going into an existing eDir tree, I strongly suggest you point to the same NTP source as your other NW or OES2 servers are pointed to.
Be sure to enter the SLP information and add the IP’s in there. Click Next.
I leave these as-is. Click Next.
I click Next here.
For us, we also scrolled down to the LUM section and configured it. We chose to LUM-enable ALL Services except for FTP currently. You can do this later, but if you know you want to LUM-enable everything, might as well do it now.
(as an example, it won’t LUM enable login, etc. We chose to change those items).
You would click the “Linux User Management” to configure.
The Directory Server Address should be the IP of the OES2 server you’re currently installing. Normally all the blanks are filled correctly at this point. Leave the proxy user/password section blank. Just make sure that the Unix config context is pointed to the highest level in your tree (usually the O=ABC or whatever), and that the Unix workstation object context MATCHES where the server will be installed to (ie, the edirectory container).
I click Next here.
Click the Select All and then UNCHECK ftp. (again, up to you)
Then click Next
You are then taken back to the original install screen and you can click Next to proceed.
Now wait a long time for this and iManager to install.
Note: There is a “bug” in this install. If you are installing a server (the 2nd or 3rd server) into an existing eDir tree with just a [ROOT] replica and it’s a large tree, and it takes more than 5 minutes to add the replicas onto the server, your eDirectory install will fail here. No amount of retries will fix the situation in that case. I don’t know why Novell coded it this way (NetWare does not have this problem). Your only remedy in that case is to partition the tree further, or add two more NetWare servers and have this be the 4th server, so that it won’t get an automatic replica copy.
For now we leave this be local. We may change to LDAP later, but unsure (plus there’s a LUM module in OES as well). Basically this means that any accounts created on this Linux server are ONLY stored on this server (same for passwords). We don’t plan on creating other “local only” accounts.
We can always clone it for autoyast later, but until we get all the specifics ironed out, I’m un-checking this and click Finish.
Technically at this point, you are finished with the install. However, it is STRONGLY advised that you patch the server before:
- Creating any NSS items
- Enabling MPIO (multi-pathing)
- Doing an ID-Transfer (or any migration with the Migration Utilities)
This assumes you are using an SMT server to patch. You can use alternative methods to patch however. The key point is that you really really really want to patch your system BEFORE attempting any further configuration or migration changes.
Once the server is up and running, before creating any NSS partitions or enabling Multi-pathing, we need to apply updates. We have setup an SMT (Subscription Management Tool) server on Linux (the same server that hosts our install media and our Auto-yast configurations). SMT is a patch “proxy” server that downloads all the patches from the Novell Customer Center (NCC) so that we don’t have to configure every server to download these patches from the internet. Instead, we point the servers to the SMT server. Think of it as a “lite” version of Patchlink for Linux/OES2. If you do not have an SMT you can register with the NCC and put your registration codes in and pull the updates from Novell’s servers.
You may either use the SLES/OES2 server to get the SMT conf file or you can use WinSCP and copy it from your PC to the SLES/OES2 server.
Once you have the script from the SMT server:
chmod +x clientSetup4SMT.sh
./clientSetup4SMT.sh –host smt.abc.com
That’s a ” – -” (dash dash without a space) in front of the host line
Hit Enter and wait
The icon will normally be orange at this point. (Green means you have all security and mandatory patches applied, but that you have OPTIONAL patches to apply. A “globe” icon means you are fully patched—even optional ones).
It will usually come up and tell you a few patches to update. Update those (this updates the ZMD process itself).
If it needs a reboot, it will tell you.
I would advise rebooting the server at this point, as sometimes it’ll hang on the next step if you don’t.
After the reboot, wait a minute or two and then the icon should show up again. Click it again (unless it’s a globe).
Wait a little while longer (or reboot if you want) and then it’ll usually come up with a list of many packages to update.
The default list will contain security patches first, followed by “mandatory/recommended” patches to SLES10 and OES2.
I usually apply those (reboot needed I believe)
After that, you’ll usually get a GREEN icon like above. I do NOT apply the optional patches.
After patching, you may have problems with iPrint Plugins in iManager on OES2 SP2. Check out TID #7005152. You’ll have to change the property pages for two objects.
This section is how to enable multi-pathing (MPIO) when booting from the SAN. As you can see, we have two paths.
Now, we follow TID #3594167 (which states we need a fully patched system, so that’s why I patch first).
So far we’ve done steps 1-4, now we do step 5.
(Quit out of the partitioner)
Open a terminal and type:
(as per step 5)
Edit multipathd.conf file as per Xiotech:
At the prompt type:
Enter the information as shown:
(note the spaces).
We may change round-robin, but I’m not sure yet. Have to find out from Novell about clustering and if this is acceptable.
STEP 8 from the Novell TID:
(there didn’t appear to be any changes required when I tested)
Reboot the server
Open a terminal prompt and type:
Here’s a key for the output of the multipath command:
For the OES2 Cluster servers, this section should only be used for ADDING new LUNs. There is nothing we need to currently do for EXISTING NSS LUNS.
To configure NSS, you must add devices to the physical server first. This means carving out LUNs.
Currently, on a standalone server, we currently have one LUN for all volumes. On the Cluster servers, each volume is a LUN.
For OES2, we will be creating one LUN for the OS, and at LEAST one more LUN for the data volumes.
Use the appropriate utility for creating the LUN. It is strongly recommended that you do not create multiple LUNs of the same size because it makes it difficult to figure out which LUN is to be used for what. If you do need identical LUNs, create the LUN one at a time, then create the NSS volume/pool on it, and then create the second LUN, etc. That way there’s no confusion.
Do not partition the LUN. Ensure that the OES2 server sees the LUN. You can verify by running the Yast -> Partitioner.
Once you’ve verified that the system can see the LUN (may require a reboot), you can then use iManager to create the NSS pools/partitions in preparation for migration.
We are going to create pools with the SAME NAME and equal or greater size for servers that we are going to migrate from NetWare.
To do this, login to iManager on an OES2 server (you don’t have to use the iManager on the actual OES2 server you’re working on, but you can do that if you want).
Go into iManager -> Storage -> Devices
Use the magnifying glass icon thingy to find the server you are wanting to create the NSS volume on and wait for it to retrieve the system information. (sometimes it takes a few seconds).
Select the appropriate device from the list (in this case, I am selecting “sdb”). You’ll notice that the Initialize button is now selectable. Double-check the Capacity to make sure you have selected the proper LUN. Please use this with caution. If you initialize the wrong disk, you will permanently erase all the data on it.
Now click Initialize Disk.
If you are certain, click OK.
After a few seconds, the Devices screen in iManager will have updated to reflect the newly initialized disk.
Now, access the Volumes menu on the left-hand side.
Enter the volume name (if migrating make sure this volume name matches the name of the volume from the “source” server).
Click New Pool
I like to keep the volume and pool name the same (it’ll add a “pool” to the pool in eDirectory).
Check the box next to “used size” and enter in the amount you want to use. For most of our servers we are letting the volume grow to the size of the pool. The Pool, by default, will be the same size as the LUN itself. Check the box Mount on Creation
Check the box for the desired pool and click Next (this is assigning the volume to the pool). A quota of zero means that it can use all the space.
So I checked the box next to “GW” and clicked Next
For our (your environment may vary) NON-GroupWise volumes, you want the following attributes. We use Symantec NetBackup which doesn’t let us use Compression. Otherwise we would enable it:
- Directory Quotas
- Set the Lookup Namespace to be Long
For GW volumes, you want:
- Flush Files Immediately
- Set the Lookup Namespace to be Unix
We are not going to enable Compression on any volumes. NetBackup doesn’t work with it (it will decompress them anyway).
I checked the “Allow Mount point to be Renamed” and clicked Finish
NOTE: While the Novell OES2 documentation states that it’s advised to NOT use the Unix lookup Namespace (in fact, it defaults to Long), it has been suggested that for GROUPWISE only (with less than a million files) that you use Unix to force case-sensitivity. I have tested unix namespace with groupwise and it seems to work okay. Plus it makes changing the case significantly easier.
According to the docs, if you enable directory quotas (like for H drives and stuff), you have to do this after you create the volume:
Lastly, for GroupWise volumes, we have to use a special switch in the /etc/fstab file to not adversely affect performance.
Edit the /etc/fstab file (you can use vi or gedit)
Find the line where it mounts the GW volume and add the word: noatime before the 0,0 like shown below:
During the testing scenario, we discovered that if you choose DHCP during the installation, it doesn’t prompt you for the same installation screens that you need, vs if you install DHCP after the initial server install.
Based upon that (in order to get the same screens as Novell’s own documentation), you have to install OES2 without DHCP, and then after the server is installed and setup, go into YaST and add DHCP pattern.
So this assumes the server has been installed and setup, but nothing migrated yet.
Therefore, go into YaST -> Open Enterprise Server -> OES Install & Configuration
Check the box next to: Novell DHCP. Notice that it’s a black check mark and the others are all blue.
You’ll be notified that you need more information. I believe you click the blue line that says: Novell DHCP Services to get to the config screens.
Login to the eDir Tree, click OK.
Pay close attention to the next screen.
The DHCP Server context will default to where the server is currently installed. This is okay.
The DHCP Server object name will default to use the CURRENT server name (remember we are doing an ID Transfer/Migration)
Make sure to change the Locator Context and Group context fields so that they reside in your most upper level of your tree (ie, the O=ABC or whatever).
See next page for a sample “final” screen.
The eDirectory server address should be the same IP of the OES Migration server (in other words, don’t put in the DIS01 or DIS03 IP’s). I believe it will use the IP already assigned.
Enter the admin credentials to login.
You should see the one network card. Click Next.
Now you are taken back to the summary screen. Click Next.
Click Finish (assuming you have a successful install).
If you get this screen, make sure to select Configure Later and click Next.
Please refer to the Migration Utility document for how to use the MigGUI to migrate DHCP along with the other services.
This is for Symantec NetBackup to work properly with NSS.
You need to edit the /etc/opt/novell/nss/nssstart.cfg file and add the two following statements/lines:
That’s an “I” in the CtimeIs statement, not an “l” ( the documentation on Symantec’s site is difficult to read).
I restart the server after this to ensure that it’s loaded.
New item on 10/1/09 – NSS file visibility issue:
We found that if you have large data sets, not all the files/directories will show up on the Windows workstation. This is due to a default setting on OES2 with ncp settings. To fix, open a terminal and type:
ncpcon set MAXIMUM_CACHED_SUBDIRECTORIES_PER_VOLUME=500000
NEW ITEM on 9/29/09 – install HP PSP in order to use Insight Agents:
Install the Proliant Support Pack (for regional servers) and reboot and verify that the NSS volumes and other items are mounted and work properly. There are some issues with the latest PSP (8.40) and generating tainted kernel messages.
NEW ITEM on 6/20/10 – Address LUM issues with namcd:
Due to some issues with LUM and reliance upon the LDAP services for NSS, etc. we advise changing the /etc/nam.conf file. Normally this file will contain the following line:
preferred-server=IP of the OES2 server you just installed
We found some issues with migrations where the server may not have a replica on it, so it doesn’t get an LDAP referral properly. We have been changing the above IP address to point to an LDAP server that contains replicas of all items in the tree. However, this can also introduce a single point of failure. To that end, we have ADDED the following line to compensate (we have 3 LDAP servers with replicas of the entire tree).
alternate-ldap-server-list=IP1, IP2, IP3
Where IP1 = secondary LDAP server with R/W replicas
Where IP2 = tertiary LDAP server with R/W replicas
Where IP3 = the local server itself (ie, if the WAN link goes down, then it will ask itself for LDAP
stuff—after the migration the server would have a R/W replica of its own partition).
We need to change a few more items.
Login to NRM (Novell Remote Manager) on the temporary OES2 server, using the following format:
https://dnsnameofserver.abc.com:8009 (same as it is for NetWare)
You must login as admin.dec or the “root” user. You cannot login as yourself just yet.
Click “Manage NCP Services” -> Manage NCP Server
Click the value of “2” next to the OPLOCK_SUPPORT_LEVEL and set to a value of 0 (that’s a zero).
NRM will automatically restart the ndsd process to make the change take effect.
We want NRM to be able to email us for the few conditions it can detect in Health monitor.
Now click the “configure” icon:
Click the “Edit httpstkd config file”
Scroll all the way down to the bottom and ADD the following two lines:
Then click Save Changes.
You now have two choices. You can either restart the entire server, or restart the following process to make the Email changes take effect:
rcnovell-httpstkd restart (this may also take a minute or so) – this makes the email change take effect
Installation Source Options
Our regional servers have such slow WAN links that we decided to place the .ISO files for SLES 10 SP3 and OES2 SP2 on the local server itself (assists with patching and any changes to the software for Yast).
- Created a local directory off of the root file system called: /iso-media
- Used WinSCP to transfer the SLES and OES2 .ISO files into the above directory (don’t forget to exclude that from your tape backup or else that’s almost 3-4 GB of data you don’t need to backup across your WAN).
- Run Yast (or yast2 from an SSH Session). Select Software -> Installation Source. It will probably complain that it can’t find the DVD/CD or wherever it was that you installed your server from (unless it was a network-based installed). Click OK and remove the sources if that’s the case.
- Click Add -> Local Directory. Click Next
- Check the box for “ISO image” and browse to the /iso-media directory and first add the appropriate SLES 10 SP3 media file. Click Next.
- Repeat step 4-5 and this time browse for the OES2 media file.
- Synchronize with ZENworks.