TABLE OF CONTENTS: NEED TO KNOW

Transcription

1 1.3

2 TABLE OF CONTENTS: WELCOME! 2 NEED TO KNOW 2 CONCEPTS 2 USEFUL NEEDED INSTRUCTIONS 4 VIRTUAL MACHINE MANAGEMENT FOR BUBBLE COURSES 5 TROUBLESHOOTING 6 WELCOME! Hello and welcome to the PDS Survival Guide. Here below, in very few pages, you ll find a list of commands that will briefly explain and help you manage your periodic tasks. As this is NOT a complete guide, for which we divert you to either Installation Guide and Operations guide, we will assume that your installation of the PDS infrastructure is working already. NEED TO KNOW Your local PDS server get courseware from US, so please allow some time to download contents and we suggest you to avoid weekends and preferably afternoon hours to download updates. Once the course material is downloaded, there ll be no need to do it again: course is locally repeatable until it s EOL d. In case of several courses sharing some contents, only the different parts will be downloaded. Whenever a new course will be released, Partners will be advised to sync to the latest available build. This is not automatic, as for the classes and room configuration. The person in charge of PDS needs some understanding of IP protocols and Unix shells, although not too extreme for a successful management. CONCEPTS In any PDS environment: there are Classes (courses) configured on Rooms (room names) which contains hosts (Students and Instructor PCs) Manned common tasks:

3 download the course (sync_class) set the course into a room (config_room) define which PCs will be in the room (add_host) Last but not least: PCs in rooms need to boot via network.

4 USEFUL NEEDED INSTRUCTIONS Conventions used: command (type as it is) parameters (below are just examples - use your own) To add a new room: add_room Room_A -network To download, or update, a course material: sync_class D64256GC10_BUBBLE_i686 To assign a course to a room: config_room Room_A D64256GC10_BUBBLE_i686 To add a PC to a room: Instructor PC: add_host PC1 Room_A x86 -mac 00:26:18:d2:93:19 - ip instructor 1 -arch i86pc -karch i86pc -installtype Install -larch i686 Student PC: add_host PC2 Room_A x86 -mac 90:e6:ba:bb:13:98 - ip arch i86pc -karch i86pc -installtype Install -larch i686 To move a PC into a different room: move_host PC1 Room_B To check what is already downloaded: classes To check for rooms: list_rooms To check the status (PCs into rooms): jsstatus To delete a class (EOL d course or disk full): delete_class D64256GC10_BUBBLE_i686

5 VIRTUAL MACHINE MANAGEMENT FOR BUBBLE COURSES Use accounts are set as vncuser / vnctech for all machines. You'll see a linux desktop. Probably the keyboard layout is U.S. English, choose yours from System / Preferences / Keyboard on the top menubar. Add layouts, YOUR OWN, as the default, then "Up" to have it as first choice. This will last for the entire course. Do check, as root * (su - root) if the virtual machine is running with the following command: xm list If you can not find host01 in the 2 lines of response (Domain-0 and host01) you have to restart the virtual machine with: xm create /etc/xen/host01.cfg as root as well. Keep in mind that this will happen after any reboot: the virtual machine does not seem to start automatically during boot. The xm create command takes a few minutes to start the host01 VM... To login to the virtual machine, you must use the vncviewer that only asks about password (which is oracle, anyway). When it does work, it works right away, otherwise after a few seconds says "no route to host". Wait a few moments and try again. You can carry on from here. * The passwords used for root accounts are the standards set into the PDS Server.

6 TROUBLESHOOTING Log files. If you encounter problems, first check the following log files. They provide useful information. On the OUIF server: /var/log/edujump.log This log is the main log for the server. When things go wrong, this is the first log to check. It contains a sequential log of activity for both the server and the clients. /var/log/edujump_status.log This log is intended to provide a snapshot of the state of the client systems. On the clients: /var/sadm/system/logs/edujump.log This log has the client Bundle installation log. It contains a lot more detail than what is seen in the edujump.log on the server. Any errors during the install will be captured here. /var/sadm/system/logs/begin.log This log is the normal Solaris pre-install script log. If there were any errors by OUIF when setting up to install, it is recorded here. Note: During the install, this log is located in /tmp/ begin.log. /var/sadm/system/logs/finish.log This log is the normal Solaris post-install script log. If there were any errors by OUIF when doing post-install work (before the first reboot), it is recorded here. Note: During the install, this log is located in /tmp/finish.log. /var/sadm/system/logs/install_log This log is the normal Solaris install log. If Solaris Jumpstart encountered any installation problems, it is recorded here. Note: During the install, this log is located in /tmp/install_log. Common problems. When, after a successful installation of a Soalris x86 based course, the graphical display server (xorg) can t be started, please log-in as root, type kdmconfig, select XSUN instead of XORG and then choose your peripherals accordingly. Here you can set the keyboard layout as well. If any course based on x86 fails to install via network, please check if dhcp server daemon is online by typing: svcs grep dhcp if found in maintenance state, please upgrade Solaris to a newer version or apply the dhcpd patch (SPARC) or (x86). When, during boot on linux courses, you ll see this on client screen: Error Parsing Kickstart Config The following error was found while parsing your kickstart configuration: The following problem occurred on line 14 of the kickstart file; Specified nonexistent disk sda in clearpart command add -p LINUX_BOOTDEV=hda to the add_host syntax. When adding rooms, please specify the netmask as it is on /etc/netmask for the base network for classes. When asked for a password during a sync_class or scp (welcome message) this means that the hostname or the rsa key have been changed, possibly for a new installation or regenerating ssh keys. The public key has to be sent to your Oracle representative to ask for a new authorization.

7 PDS installation is very sensible to network data changes. Please remove and reinstall the package when this changes occurs. During upgrades of the OUIF package, /etc/ethers file is deleted. Please copy it to a safe location before any upgrade. Whilst this is not used by x86 systems, it is used for SPARC systems in the classrooms. Client hangs during the install. Often the cause of this is a misconfigured Solaris sysidcfg file. The most common error is a bad netmask. In SEIF and later, config_room will generate the sysidcfg file for you with the correct netmask if it is able to find it in /etc/netmasks. There is also a new parameter in the room.cf to specify the netmask, JSR_ROOM_NETMASK, which will be used instead of /etc/netmasks entries. Configuration changes to not take effect. This problem comes when a room configuration file is changed by hand. It is strongly recommended that any changes to the room files be done via the commands listed above. Having said that, if you wish to modify the room configuration files by hand, ALWAYS disable the room first. This will prevent most of the problems as it erases OUIF's cache and removes all configuration data from the operating system. In SEIF and later, config_room will always regenerates the room configuration completely for you, taking into account any changes to your server name, latest entries in /etc/hosts, and so forth, which can often resolve any configuration problems you may encounter. Graphics do not start on an x86 system, or an intervention is required during jumpstart to answer prompts about Xorg. The most common problem here is that the mouse or graphics cannot be recognized or detected (hardware unable to probed by kdmconfig). You can use the add_host Property "XORG_DEFAULT=1" that causes the file /seif/solaris/sunos/x86/ xorg.conf.1 to be installed on the host, and completely bypasses the running of kdmconfig during jumpstart, avoiding the problem of manual intervention during jumpstart. Normally, headless systems would use something like Xvnc for graphical desktop, so the default xorg.conf file would not be used, but if for some reason, custom xorg.conf files are required to support different x86 units, they can be added in directory /seif/solaris/sunos/x86/ and named as xorg.conf.foobar, for example, and referenced as XORG_DEFAULT=foobar in the add_host property.) Cannot see all the console messages on an X86 headless server. To fix this problem, you will need to specify the add_host property SOL_CONSOLE=ttya when adding the host. This redirects the system console from a graphics card (which in this case does not exist) to serial port A. Or you can specify SOL_CONSOLE=ttyb for serial port B, and so on. (This results in the appropriate console redirection parameter being added to the GRUB menu for the host.) Wrong disk controller is being used for the boot drive. There are some x86 units whose boot drive is not controller "0" (commonly referred to as c0). To specify another boot drive controller for a particular host, specify the add_host property HD_CONTROLLER=c1, for example, to specify controller "1". In Solaris 10 releases, the DHCP/BOOTP server seems not to be listening to anything but the interface that matches the hostname. This problem can usually be resolved by changing /etc/ nodename and using the hostname command to match to the interface connected to the x86 units you are trying to jumpstart. CAUTION: Solaris OUIF servers supporting x86 targets when /seif/os directory is placed on a ZFS file systems, and ZFS is not set to mountpoint=legacy Whenever a Solaris server is rebooted, the /etc/vfstab file mounts will be attempted by Solaris before all ZFS file systems are ready, unless the ZFS filesystem has mountpoint=legacy and is mounted explicitly via /etc/vfstab. For further information on this problem, please refer to:

8 This problem occurs with local filesystem mounts specified in /etc/vfstab which are being mounted from ZFS filesystem space, and the ZFS filesystem does not specify mountpoint=legacy and appear in /etc/vfstab.. This problem occurs only for x86 clients because OUIF uses the Solaris add_install_client script to configure x86 clients for jumpstart, which generates a local file mount of the bootstrap program in the /seif/os/ installation files onto a file in the /tftpboot directory and adds this local mount to /etc/ vfstab. When /seif/os has been installed on a ZFS file system that does not specify mountpoint=legacy, the server cannot boot beyond single-user mode. To correct it at the system console, unmount the zfs pool containing /seif/os, then set the ZFS filesystem to have mountpoint=legacy, and add the explicit mountpoint of the ZFS filesystem to / etc/vfstab above the other /seif/os local file mounts, generated by add_install_client then run 'mountall' to restore tall he mounts in the correct order. CAUTION: /etc/inet/hosts file containing comments with valid hostnames in them can sometimes break the Solaris add_install_client for creating an x86 client GRUB menu. Whenever the /etc/inet/hosts file contains comments with valid hostnames that match the JSR_DEFAULT_ROUTER, there is risk of breaking the add_install_client function of creating the GRUB menu. There is a bug in the Solaris add_install_client where it does not parse comments properly, and generates invalid GRUB menus with "#" for host IP addresses, for example. Avoid using hostnames in comments to avoid this bug.