opsi Version 4.0.5 Release Notes

uib gmbh


Table of Contents

1. Copyright
2. Overview of the new features
3. Known Bugs / Known Problems
4. Samba 4
5. Discontinuation
5.1. Discontinuation: Windows versions
5.2. Discontinuation: opsi products
5.3. Discontinuation of Python 2.5 support
6. Installation notes
6.1. Installation notes regarding opsi server vm Version 4.0.4
6.2. Installation notes regarding RHEL / CentOS
6.3. Notes for updating opsi-packets
6.4. Hints for updating the Java Runtime Environment
7. opsi-configed 4.0.5.
7.1. Depot server selection
7.2. Client reachability
7.3. Failed Actions
7.4. Product default properties
8. Opsi-linux-bootimage
8.1. Fallback byAudit
9. opsi Linux Support
9.1. Preconditions for using the opsi Linux Support
9.2. Introduction
9.3. Linux Netboot products
9.3.1. Common properties of the Linux netboot products
9.3.2. Netboot products for Linux distributions
9.4. opsi-linux-client-agent
9.5. opsi-linux-client-agent: Known Bugs
9.5.1. opsi-linux-client-agent: installation paths
9.5.2. Script examples
9.6. Linux localboot products
9.6.1. l-os-postinst
9.6.2. l-desktop
9.6.3. l-system-update
9.6.4. l-swaudit
9.6.5. l-hwaudit
9.6.6. l-jedit
9.7. Inventory
9.8. UEFI / GPT support
9.9. Roadmap
9.10. Proxy for deb packets
10. opsi with UEFI / GPT
10.1. Preconditions for working with UEFI / GPT
10.2. Introduction
10.3. What is UEFI and what is different about it?
10.4. What is different about GPT
10.5. UEFI Boot
10.6. UEFI Netboot
10.7. opsi support for UEFI netboot
10.8. Installation
10.9. Configuration of the DHCP server
10.10. Criteria for a good BIOS
10.11. Technical details
10.11.1. Technichal details about UEFI
10.11.2. Technichal details about GPT
10.11.3. opsi UEFI/GPT Roadmap
11. opsi Extension opsi-clonezilla
11.1. Preconditions for the opsi Extensions opsi-clonezilla
11.2. Introduction
11.3. Concept
11.4. Interactive Proceedings
11.4.1. Interactive savedisk in the expert mode
11.4.2. Interactive savedisk
11.4.3. Interactive savepart
11.4.4. Interactive restoredisk
11.4.5. Interactive restorepart
11.5. Not interactive processes
11.6. opsi-clonezilla known bugs
11.7. Clonezilla command reference
12. opsi extension opsi local image
12.1. Preconditions for the opsi extension opsi local image
12.2. Introduction
12.3. Concept
12.4. Technical Concept
12.5. Components
12.5.1. netboot product for partitioning
12.5.2. netboot products for installing Windows
12.5.3. Netboot products for installing Linux
12.5.4. Netboot product for backup and restore
12.5.5. Localboot product for process control
12.6. Extended opsi service methods
12.7. Process steps
12.7.1. Initial Installation
12.7.2. Restoring an image
12.7.3. Updating an image
12.7.4. Deleting an image
12.8. Backup partition
12.9. Capture Images (WIM) generating and distribution
12.9.1. Capture Images (WIM) Introduction
12.9.2. Capture Images (WIM) Components
12.9.3. Capture Images (WIM) Processing
12.10. Creating an own Ubuntu proxy
13. opsi Setup Detector
13.1. Introduction
13.2. Preconditions for using the opsi Setup Detector
13.3. Setting up the opsi Setup Detector
13.3.1. Language Support
13.3.2. Files of the opsi Setup Detector
13.4. The Menu of opsi Setup Detektor
13.5. Automated Analysis of a Setup file
13.6. Setup-EXE with embedded MSI
13.7. Supported Installer Types
13.7.1. Installer Type MSI
13.7.2. Installer Type Advanced+MSI
13.7.3. Installer Type Inno Setup
13.7.4. Installer Type InstallShield
13.7.5. Installer Type InstallShield+MSI
13.7.6. Installer Type NSIS
13.8. Creating a new opsi Packet
14. Miscellaneous
14.1. Changelogs:
14.1.1. Changelog opsi-configed
14.1.2. Changelog opsi-client-agent
14.1.3. Changelog opsi-winst
14.1.4. Changelog windows netboot products
14.1.5. Changelog linux netboot products
14.1.6. Changelog opsi-local-image
14.1.7. Changelog python-opsi
14.1.8. Changelog opsipxeconfd
14.1.9. Changelog opsiconfd
14.1.10. Changelog opsi-utils
14.1.11. Changelog opsi-linux-bootimage
14.1.12. Changelog opsi-depotserver
14.1.13. Changelog opsi-atftp
14.1.14. Changelog opsi4ucs
14.1.15. Changelog opsi-swaudit
14.1.16. Changelog opsi-template

List of Figures

7.1. opsi-configed: Depot server selection
7.2. opsi-configed: Client is reachable
7.3. opsi-configed: Client not reachable
7.4. opsi-configed: Failed Actions
7.5. opsi-configed: product default properties
11.1. Skip: The share given by the property imageshare will be mounted by the bootimage to /home/partimg.
11.2. Mounted partitions.
11.3. Expert or Beginner ?
11.4. Choose operation.
11.5. Choose the tools (default value recommended)
11.6. miscellaneous: unset -c here to suppress interactive questions for automation.
11.7. compression method before opsi 4.0.5, which is bootimages ⇐ 20130207 (opsi-clonezilla_2.01-3), select here -z1. With opsi 4.0.5 and above not required anymore.
11.8. Check filesystem (den default skip nutzen)
11.9. Check the saved image (den default yes nutzen)
11.10. Action after cloning (use the default -p true, the reboot is triggered by the opsi bootimage).
11.11. Name for the image to be saved on disc.
11.12. Select the disc to create the image from
11.13. The resulting command. This can be set as product property runcommand
11.14. Progress bar
11.15. Name for the partition image to be saved as.
11.16. Select the partition to create the image from
11.17. The resulting command. This can be set as product property runcommand
11.18. Progress bar
11.19. Selct the disc image to be restored
11.20. Select the disc where the image is to be restored to
11.21. The resulting command. This can be set as product property runcommand
11.22. Query before starting to overwrite the disc. Can be supressed by omitting the option -c from the command.
11.23. Progress bar
11.24. Select the partimage to be restored
11.25. Select the partition where the image is to be restored to.
11.26. Query before starting to overwrite the disc. Can be supressed by omitting the option -c from the command.
11.27. Progress bar
12.1. schema: static partitioning with opsi-local-image-prepare
12.2. schema: OS installation with opsi-local-image-win*
12.3. schema: image backup with opsi-local-image-backup
12.4. schema: image restore with opsi-local-image-restore
12.5. capture images: configed: opsi-local-image-sysprep
12.6. capture images: configed: opsi-local-image-capture
12.7. capture images: schema: sysprep
12.8. capture images: opsi-local-image-sysprep 1 : start
12.9. capture images: opsi-local-image-sysprep 2 : backup before sysprep
12.10. capture images: opsi-local-image-sysprep 3 : deactivating the opsi-client-agent
12.11. capture images: opsi-local-image-sysprep 4 : actual sysprep
12.12. capture images: schema: capture 1
12.13. capture images: schema: capture 2
12.14. capture images: capture: delete an existing image
12.15. capture images: capture: capture and append the new image

List of Tables

9.1. Required packets
10.1. required packets
10.2. Example for UEFI BIOS differences
11.1. Needed product and package versions
11.2. Needed product and package versions
12.1. Required packets

Chapter 1. Copyright

The Copyright of this manual is held by uib gmbh in Mainz, Germany.

This manual is published under the creative commons license
Attribution - ShareAlike (by-sa).

CC by sa

A German description can be found here:
http://creativecommons.org/licenses/by-sa/3.0/de/

The legally binding German license can be found here:
http://creativecommons.org/licenses/by-sa/3.0/de/legalcode

The English description can be found here: http://creativecommons.org/licenses/by-sa/3.0/

The English license can be found here: http://creativecommons.org/licenses/by-sa/3.0/legalcode

Most parts of the opsi software are open source.
The parts of opsi that are not open source are still under cofunded development. Information about these parts can be found here: http://uib.de/en/opsi_cofunding/index.html

All the open source code is published under the GPLv3 and is moved to AGPLv3 while releasing opsi 4.0.3:

The legally binding GPLv3 license can be found here: http://www.gnu.org/licenses/gpl.html

agplv3

The legally binding AGPLv3 license can be found here: http://www.gnu.org/licenses/agpl-3.0-standalone.html

Some information around the AGPL: http://www.gnu.org/licenses/agpl-3.0.en.html

For licenses to use opsi in the context of closed software please contact the uib gmbh.

The names opsi, opsi.org, open pc server integration and the opsi logo are registered trade marks of uib gmbh.

Chapter 2. Overview of the new features

The opsi Service Release 4.0.5 comes with a whole bunch of new features and improvements. Here a survey:

  • with opsi 4.0.5 (exclusively) the following distributions are supported as opsi-server:

    • Ubuntu: 10.04 (Lucid), 12.04 (Precise), 14.04 (Trusty)
    • Debian: 6.0 (Squeeze), 7.0 (Wheezy)
    • UCS 3.2
    • openSUSE 12.3, 13.1
    • SLES 11SP3
    • RHEL 6.6, 7
    • CentOS 6.5, 7

Important

Please observe that the opsi-configed of version 4.0.5.x requires a Java version of at least 1.7.0.

If you are using an OS version which is not contained in the list above, we recommend updating the OS before installing opsi v 4.0.5.

  • opsi server components:
    Diverse improvements and bugfixes for the server packets.
  • New opsi-bootimage based on Ubuntu Precise / Kernel 3.15.1 supporting new hardware (like tablets), UEFI support and support for Linux disc encryption.
  • Windows netboot products

    • Driver integration per byAudit also for vendor and model of the motherboards
    • When applicable full UEFI/GPT compatibility
    • New property setup_after_install for automation.
    • Support for HP SmartArray RAID Controllers
  • opsi-winst / opsi-script (4.11.4.10):

    • Logging changed to c:\opsi.org\log\opsi-script.log
    • New constants:

      • %opsiDepotId% : Depotserver // since 4.11.4
      • %opsiTmpDir% : c:\opsi.org\tmp // since 4.11.4.3
      • %opsiLogDir% : c:\opsi.org\log // since 4.11.4.3
    • New features for handling key/value pairs in config files:

      • String function: getValueFromFile(<key string>, <file name>) //since 4.11.4.4 [W/L]
      • string function: getValueFromFileBySeparator(<key string>,<separator string>,<file name>) //since 4.11.4.4 [W/L]
      • PatchTextFile section commands:
      • setKeyValueSeparator <separator char> //since 4.11.4.4 [W/L]
      • setValueByKey <keystr> <valuestr> //since 4.11.4.4 [W/L]
    • Encoding functions (please read the manual !):

      • string function reencodestr( <str> , <from>, <to> )
      • stringlist function reencodestrlist( <strlist> , <from>, <to> )
    • Show Activity:

      • At winbatch sections with /timeout a progressbar will show the time to timeout
      • new switch: AutoActivityDisplay = (true/false) default=false; if true shows a marquee (endless) progressbar while winbatch/dosbatch sections are running.
      • new parameter for dosinanicon: /showoutput : shows a windows with the continuous output of the command while running
    • Miscellaneous:

      • new bool function: saveTextFile(<list>, < filename>) //since 4.11.4.4 [W/L]
      • stringlist function shellCall( <cmd> ) ; returns the output of (sysnative) shell with cmd
      • command IncludeLog with additional encoding parameter
      • new stringfunction: strLoadTextFile ( <filename> )
      • new bool function: LineContaining_ExistsIn( <string>, <file name> )
  • Miscellaneous products:

    • Fixes in swaudit
  • opsi-configed:

    • It is now possible to set the (depot-)server product property defaults via configed
    • many new features and improvements: for details see corresponding chapter.
  • opsi Linux support:
    see corresponding chapter
  • opsi uefi (Netboot) Unterstützung:
    see corresponding chapter
  • Images with opsi clonezilla:
    see corresponding chapter
  • opsi extension opsi-local-image (for restoring class room clients):
    see corresponding chapter
  • opsi-setup-detector (wizard for creating opsi packets):
    see corresponding chapter
  • opsi-client-agent:

    • fixes for Windows 8.x (Loginblocker)
    • property uac_level=0 does not change the UAC level
      We recommend to set property uac_level=0 to the default. This can easily be done by the new configed.

Chapter 3. Known Bugs / Known Problems

KNOWN BUGS:

  • openSUSE 13.1, CentOS 70:
    Accordining to the new network interface names they may be a wrong nemask information in the opsi backend.
  • opsi-clonezilla:
    The handling of linux system (ext filesystem) is broken right now.

KNOWN PROBLEMS:

  • configed:
    On XP host there is a great probability that the configed webstart version does not start. The reason is that it reports a max heap requirement of 1000 MB, but XP does not offer it, even if it exists. We recommend to use the opsi Localboot product opsi-configed and reduce the product property "memory_requirement" for the XP client e.g. to 512 MB.
  • opsipxeconfd:
    On RHEL / CentOS Warnings while upgrade to opsi 4.0.5
  • opsi-linux-bootimage:
    Because of changes in lshw the model read during hardware inventory can differ from previous versions. This may result in unwanted behaviour regarding the driver integration if this is done using the computer model.

Chapter 4. Samba 4

The first distributions will be delivered with Samba 4.

Currently Ubuntu 14.04 and openSuse 13.1 are equipped with Samba 4 packets. These packets are not suitable to manage whole domains, but act like Samba 4 regarding the shares.

With Samba 3 the default was, that every file or directory was executable on the clients. This behaviour changed with Samba 4. Now all files, that shall be executable from the share, must also have the executable bit set on the Unix side.

This results in a basic problem with running opsi. It is not possible to bypass this behaviour from the rights management, for it would require fundamental changes of the rights management of opsi, that can’t be done with opsi 4.

So for handling this problem with opsi 4.0 there are two ways:

Option 1: for the affected shares this behaviour can be supressed by elevating the share privileges of each member of the pcpatch group from the share configuration by setting the following option:
admin users = @pcpatch

This fix elevates the privileges of the Samba processes and has already been used by opsi for some time for UCS >= 3 with Samba 4.

opsi installs per default for Samba 4 distributions with opsi-setup --auto-configure-samba this option for the opsi_depot share. This share is mounted read only, so the safety and security risk can be estimated as low.

Option 2: instead the following global option can be set in the smb.conf:
allow general executable = True

With this option for all shares a behaviour like Samba 3 is restored.

To restore the old behaviour for all shares, the setting of the first option can be done for every share manually, or the second option can be set globally in the smb.conf. Using the second option changes the behaviour for all shares, not only for the opsi shares.

Chapter 5. Discontinuation

This chapter lists the discontinued versions. For various reasons, these distribution versions will not be supported by opsi anymore.

5.1. Discontinuation: Windows versions

With opsi v 4.0.5 the maintenance of the netboot packets for Windows Vista and Server 2008 is discontinued. Also the update abonnements will not support these Windows versions anymore. For questions or problems regarding the discontinuation please contact us.

Windows XP is not supported by Microsoft anymore and support for Windows 2003 Server ends in 2015. Because of the still frequent use of these versions, we will continue to maintain these packages for some time. Nevertheless we announce the discontinuation in short time and it is recommended to updade the clients to recent Windows versions (or Linux).

5.2. Discontinuation: opsi products

With opsi v 4.0.5 the following products are not supported any more:

  • ntfs-write-image
  • ntfs-restore-image

They are replaced by the new product opsi-clonezilla (for details see the related chapter).

5.3. Discontinuation of Python 2.5 support

Because no more updates are available for Python version 2.5, this version is not supported by opsi anymore. Opsi requires Python 2.6 or Python 2.7.

Chapter 6. Installation notes

For safety reasons we recommend before installing the update to make a backup of your backends with opsi-backup:

opsi-backup create

The products contained in this release in many cases depend on each other. So do not try to install just a part of this update.

First update the server, then the opsi products.

When upgrading an existing opsi server your package manager may ask you if you want to replace /etc/opsi/opsi.conf with a newer version. If this question appears and you did not change the mentioned file you can replace the file with the new one. If you changed the file or are unsure please deny the replacement.

As it was described above, a new version of /etc/opsi/opsi-product-updater.conf may be suggested as update. The new version gives also support for smtpusers with smtppasswords to systems that require this type authentication. Besides the value to Exclude-Files (exclude = ^win* ) was removed, so the windows-netboot-products are not excluded anymore from the updates.

We recommend to run ``opsi-setup --set-rights`` after the installation to make sure that the permissions on the used folders are set as expected. Please be aware that the execution of this task can last for many minutes.

6.1. Installation notes regarding opsi server vm Version 4.0.4

During the opsi-depotserver upgrade you may be asked again for information about a SSL certificate preparation.

6.2. Installation notes regarding RHEL / CentOS

With version 4.0.5 the dependency to python-mysql will be replaced with MySQL-python on python-opsi. MySQL-python is part of the standard repository.

Conflicts may occur during the update. To avoid this please remove python-mysql before updating:

rpm -e --nodeps python-mysql

6.3. Notes for updating opsi-packets

The installation does not require any special action. It is performed within the normal updates of your server and opsi products.

First update the server according to the update command of your Linux distribution.

We recommend to set in /etc/opsi/opsi-product-updater.conf in the section [repository_uib] the following to get all products even if they start with win* :

excludes =

If you need the opsi-linux products you should append the dirs entry:

dirs = opsi4.0/products/localboot, opsi4.0/products/netboot

by the path opsi4.0/products/opsi-linux

If you need the opsi-local-image products you should append the dirs entry by the path opsi4.0/products/opsi-local-image

Then execute the opsi-product-updater.

opsi-product-updater -i -vv

To install updates only:

opsi-product-updater -vv

In case of a multi depot installation, first upgrade the config-server before upgrading the depot server.

If you want to use product-ids with a length of more than 32 characters and are using the MySQL-backend please update the table definition on your configserver with the following command:

opsi-setup --update-mysql

6.4. Hints for updating the Java Runtime Environment

The opsi-configed now requires a Java Runtime Enviromnent (JRE) on the computer on which it is run, at least in version 7 (internal version 1.7).

If you do not run the opsi-configed on the server, e.g. because the server does not offer a graphical user interface, opsi does not require a Java installation on the server at all.

In the other case, you must get a Java Runtime Engine at least in version 7 active. If there is still an older version active you should deinstall the old one and install the new one. For Ubuntu the commands are

apt-get remove openjdk-6-jre
apt-get remove openjdk-6-jre-lib
apt-get install openjdk-7-jre

Thereafter the command

java -version

should indicate that a least version 1.7.0 is running.

Chapter 7. opsi-configed 4.0.5.

Several measures were taken to accelerate changing views in the opsi-configed. Especially, the opsi-configed now tries to get as much data in advance as it seems reasonable instead of requesting the data every time the user switches to another view.

For all hosts on which a configed is expected to run the Java Runtime Environment of at least version 1.7.0 must be installed.

7.1. Depot server selection

It is no longer necessary to perform a complete reload on changing depot selection. Simply select one or more depots and you will see the corresponding data.

The new buttons have the following specifications:

  • (=+) : Marks all depots with identical product stocks.
  • (++) : Marks all depots (you can also use Ctrl-a)

Figure 7.1. opsi-configed: Depot server selection

opsi-configed: Depot server selection

7.2. Client reachability

The feature of testing the client reachability has been modified to run in the background and then show the results in the client table. It can be enabled from the logon screen mask or via command line parameter. The default refresh interval is 0 min (= deactivated).

Figure 7.2. opsi-configed: Client is reachable

Client reachable

Figure 7.3. opsi-configed: Client not reachable

Client not reachable

7.3. Failed Actions

From the group view the group “REPORT: FAILED” has been removed. As a new feature to detect failed installations, the menu Selection offers Failures with product and Failures occurred (today, since yesterday, …).
Choose the first setting to get a list of all products. If you select a single product, all clients will be shown, where the installation of this product failed.
When choosing for instance Failures occured - today, all the clients will be marked, where an product installation failed today.

Figure 7.4. opsi-configed: Failed Actions

opsi-configed: Failed Actions - today

7.4. Product default properties

To change the default values of the products for one or more opsi-depots, there is a new tab, called Product default-properties. This is only available if you select Properties of depots (which is the second button at the top right hand side).
In the main table, all products are listed with the product version as well as the package version.

If a product is selected, at the top of the right side (as is customary for the client product configuration) general information about the product packets is shown. Below is the list of all depots, that have installed the selected product. The table below with the property keys and values is also known from the client product configuration.

Figure 7.5. opsi-configed: product default properties

opsi-configed: Product default properties

You can select a single depot or multiple depots to change the default values (which are also called the depot values) of the product. As the default, all available depots are preselected. With the usual shortcuts (Ctrl-a, Ctrl-Click or Shift-Klick) multiple or all clients can be selected.
If the property value is shown greyed (see Figure 7.5, “opsi-configed: product default properties” - “gui_language”), the values for that property differ on the selected depots. On the right side of the depots are three buttons:

  • (=+): Mark all depots that have identical values
    All depots, that have the same default values, are marked.
  • (++): All depots are marked.
  • (globe): set the packet default values
    The original packet default values of the products will be set fot the selected depot(s).

Chapter 8. Opsi-linux-bootimage

Das opsi-linux-bootimage has been basically revised and redesigned. First it had been updated to Ubuntu 12.04, because many functions that are required for the new opsi modules, are not available with Ubuntu 10.04.

So all parts of the bootimage have been updated.

8.1. Fallback byAudit

For some time opsi has the feature to automatically add the additional drivers based on the hardware inventory. This feature depends on the proper "branding" of the hardware by the hardware manufacturer. Large OEMs like Dell, HP or Fujitsu Siemens usually do a proper branding.

But more and more charges of hardware are supplied by small distributors, that do not make a proper branding. Often these clients come with identical hardware, but when trying to identify the hardware manufacturer and the device model, the corresponding values are not set.

To handle this situation, opsi 4.0.5 comes with a fallback that is based on the motherboard. This feature is basically the same as the actual byAudit driver assignment, with the only difference that, instead of manufacturer and device model, as fallback the same process with the manufacturer and the name of the board is applied.

Chapter 9. opsi Linux Support

9.1. Preconditions for using the opsi Linux Support

Technical precondition is opsi 4.0.5 with following packet versions:

Table 9.1. Required packets

opsi packetversion

opsi-linux-bootimage

>= 20140805-1


The opsi support for Linux is based on a free Open Source component (the netboot products) and a co-funded component (the client-agent).

The opsi-linux-client-agent is a co-funded opsi extension module.
For using the opsi Linux extension module, an activation file is required, which can be acquired by buying the extension module. To obtain a temporary activation file for evaluation, please email to info@uib.de.
For further details on handling extension modules refer to the opsi manual.

9.2. Introduction

A single management tool for Windows and Linux

The objective of the opsi Linux extension module is to provide a homogenous management system for heterogenous environments. The focus is on integrating both worlds into the same management processes and tools

This means, that a Linux installation is triggered the same way as a Windows installation. The Linux opsi-client-agent is based on the same source code as the Windows client and provides (when applicable) the same opsiscript instruction sets.

Independent from Linux distribution

The opsi Linux Support is designed to be independent from any special Linux distribution.
The following distributions are supported:

  • Debian
  • Ubuntu
  • OpenSuse / SLES (Suse Linux Enterprise Server)
  • Fedora / RHEL (RedHat Enterprise Linux)
  • CentOS

9.3. Linux Netboot products

Basic OS installation per netboot

For installing Linux on a client, at first the standard opsi-linux-bootimage is booted per netboot. It is the same image as being used for the Windows installation.
The bootimage automatically performs the partitioning and formatting of the hard disc (/ and swap). Next the installation of the basic Linux Operating System is performed (including network and ssh, but without X11). The installation process itself is quite different for the individual distributions, but has in common, that the installation is performed directly from the original distribution packets.

The basic Linux installation can be extended with optional opsi packets, for instance to turn the system into an opsi-Server (a new depotserver for instance).
Also the opsi-client-agent for Linux can be installed, which enables the automated installation and configuration of further software packets.

The opsi-client-agent for Linux is available as a co-funded opsi extension module, the required opsi netboot products for Linux installation are available as free Open Source modules.

Because the base installation is done from the Standard opsi-linux-bootimage, there ar some distribution dependent differences, that have to be installed and configured after the first reboot of the installed system. This is for example the se-linux installation of the RedHat like or the keyboard configuration of the Debian like systems. These after boot installations and patches are done by the standard localboot produkt l-os-postinst.

9.3.1. Common properties of the Linux netboot products

The following properties for controlling the Linux installation are available with all netboot products:

  • askbeforeinst:
    confirm start of the new installation on the client? (default=true)
  • architecture:
    architecture selection - affects the selection of the bootimage and the installation architecture. (default=64bit)
  • system_partition_size:
    size of the system partition - the size may be given as percent of the harddisk size or as absolute size (G=Gigabyte). If you choose another value than 100%, the remaining rest will be used as data_partition. (default=100%)
  • swap_partition_size: +size of the swap partition. (default=2000M)
  • data_partition_create:
    create a data partition if there is some space left. (true/false) (default=true)
  • data_partition_preserve:
    preserve an existing data partition?
    always = cancel the installation in case the preservation of an existing partition with the label data is not possible with the given partition data.
    if_possible = an existing partition with the label data is preserved if possible according to the given partioning parameters. Otherwise it will be deleted.
    never = a new partition table will be created. (default=never)
  • language:
    language / locale to be installed (default=de)
  • console_keymap:
    keyboard layout to be used (default = distribution dependent / de)
  • timezone:
    time zone to be configured (default=Europe/Berlin)
  • root_password:
    root password (default=linux123)
  • user_password:
    user password (default=linux123)
  • install_opsi_server:
    install opsi server packages (default=false)
  • online_repository:
    repository to use for installation - repository of the Linux distribution to be used for installation (not for SLES) (default = distribution dependent)
  • opsi_online_repository:
    repository for opsi-server installation - repository for the opsi-server packets (default = distribution dependent)
  • proxy:
    proxystring (if required) as: http://<ip>:<port> (default='')
  • additional_packages:
    additional packets to install. Packet names separated by blanks. (default='')
  • wget_and_execute:
    fetch a file via wget and execute it - URL (http) of a file to be executed at the end of installation. (default='')
  • install_opsi-client-agent:
    install the Linux opsi-client-agent (cofunding project: has to be activated by the /etc/opsi/modules) (default=false)
  • release:
    (Debian and Ubuntu only)
    which release of the distribution is to be installed? (default = distribution dependent)
  • setup_after_install:
    opsi product(s) to be installed after the OS installation is done (opsi products to be set to setup) (default=l-os-postinst)

9.3.2. Netboot products for Linux distributions

Ubuntu

The basic installation is performed per debootstrap directly from the network.

This product has the status productive.

It is UEFI/GPT compatible (tested for release=trusty).

For this product applicable opsi-server packets are available, that can be installed by setting install_opsi_server=true.

Debian

The basic installation is performed per debootstrap directly from the network.

This product has the status productive.

It is UEFI/GPT compatible (tested for release=wheezy).

For this product applicable opsi-server packets are available, that can be installed by setting install_opsi_server=true.

OpenSuse

The basic installation is performed by using the products embedded RPM files. Therefore each release requires a corresponding product.

OpenSuse 12.3. This product has the status productive.

This product is not UEFI compatible.

For very new releases the opsi-server packets might not be available yet. In this case using the property install_opsi_server=true might cause some errors.

OpenSuse 13.1. This product has the status productive.

This product is not UEFI compatible.

For this product applicable opsi-server packets are available, that can be installed by setting install_opsi_server=true.

Known Bugs: At some Hardware (eg. VMWare ESXi) the prediction of the network interface fails and the machine starts with unconfigured network interface.

SLES

The basic installation is performed by using the products embedded RPM files. Therefore each release requires a corresponding product.

The SLES product contains some RPMs which are not available as Open Source, so we cannot provide this product for public download. But we can provide the packet for our customers at no charge ( → mail to info@uib.de).

This product has the status productive.

For very new releases the opsi-server packets might not be available yet. In this case using the property install_opsi_server=true might cause some errors.

This product is not UEFI compatible.

This product has additional properties:

  • use_gpt
    when set to true, the hard disc (also in MBR-BIOS mode) will be partitioned as GPT. This requires a boot partition. In case the property boot_partition_size is set to 0, nevertheless a boot partition of size 1 GB will be created.
  • boot_partition_size
    size of the boot partition - in case of 0 no boot partition will be created.
  • kernel_modules
    blank separated list of additional kernel modules to be loaded (e.g. for special hard disc controller).
  • suse_register
    In case of true the server will be registered online. This requires the email address and the product key (registration key) in form of email:productkey. The key is retrieved (depending on the host parameter license-management.use) from the license management or from the property productkey.
    In case of false the property local_repositories must contain at least one suitable repository server.
  • productkey
    email address and registration key in form of email:productkey (if no license management used).
  • local_repositories
    blank separated list of repositories to be integrated per zypper, in form of: "http://myserver.local description"

The property online_repository is omitted.

CentOS

The basic installation is performed by using the products embedded RPM files. Therefore each release requires a corresponding product.

This product has the status under development. Outstanding features are: localisation.

For this product applicable opsi-server packets are available, that can be installed by setting install_opsi_server=true.

This product is not UEFI compatible.

CentOS 7. This product is not available yet.

Fedora

The basic installation is performed by using the products embedded RPM files. Therefore each release requires a corresponding product.

Fedora 20. This product has the status testing.

For new releases the opsi-server packets might not be available yet. In this case using the property install_opsi_server=true might cause some errors.

This product is not UEFI compatible.

RHEL

This product is not available yet.

9.4. opsi-linux-client-agent

The opsi-client-agent for Linux ist part of the co-funding project Linux Agent, which is liable to pay costs.

The opsi-client-agent for Windows is based on two components:

  1. the service opsiclientd
  2. the action processor opsi-winst / opsi-script

The opsi-client-agent for Linux is based on the Linux port of the Windows client agent.

With the first release of opsi Linux, the Linux port of the opsiclientd has not been completed yet, so it is replaced by the opsiscriptstarter, which performs the following opsiclientd tasks at system start:

  • connect to the opsi-server: check whether actions are to be performed
  • mount the depot share
  • start the action processor
  • unmount the depot share
  • transfer the logfile to the server

The Linux action processor is named opsi-script and is built from the same sources as the Windows opsi-winst. So on Linux the same scripting syntax is available as on Windows. All common features, that are not Windows specific, are available, as there are e.g.:

  • file handling
  • string and stringlist functions
  • executing external scripts and programs
  • communication with the opsi-Server
  • patching config files

Of course Windows specific features (like patching the Windows registry) are not available on Linux, but there are some additional Linux specific functions like e.g.:

  • getLinuxDistroType
  • getLinuxVersionMap

Logging of the opsi-script ist available (like with the opsi-winst on Windows).

Linux opsi-script is available as a grafical version for working with X-Windows and a noGUI version for systems without grafical user interface.

9.5. opsi-linux-client-agent: Known Bugs

Copy a bundle of files via Files section from a smb share may fail according to the Samba version

Workaround: Instead of:

[Files_copy_netboot]
copy -s "%scriptPath%/installfiles/*" "$target$/installfiles/"

you may use:

[ShellInAnIcon_opsi_copy_netboot]
set -x
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
cd "%scriptPath%"
tar cf - installfiles | ( cd "$target$/installfiles/" ; tar xf - )

9.5.1. opsi-linux-client-agent: installation paths

As usual on Linux, the linux-opsi-client-agent is spread to several directories:

the binaries:

/usr/bin/opsi-script (X11)

/usr/bin/opsi-script-nogui (without X11)

/usr/bin/opsiscriptstarter (preliminary opsiclientd replacement)

auxiliary files:

usr/bin/winstskin/

config files:

/etc/opsi-client-agent/opsiclientd.conf (configuration of the opsiscriptstarter/opsiclientd)

/etc/opsi-client-agent/opsi-script.conf (under construction)

logfiles / temporary files:

/var/log/opsi-client-agent

9.5.2. Script examples

For software deployment on Windows clients there can be said: the installation of software itself is as important as the subsequent configuring of the software.
On Linux most packets are available from the distribution repositories. So the installation part is less, but the configuration part stays the same. Also there are applications, that are not available from the standard repositories. In this case special repositories or installation sources have to be added to the system. The important feature is, that all installation and configuration settings can be managed and logged on the opsi-server.

Here are some example snippets for an opsi-linux-client-agent opsi-script:

  • exit in case the script detects a non Linux system
  • detecting the distribution type (to use apt-get, zypper or yum)
  • detecting the Linux version
  • installing a packet
  • adding a repository

Example: exit in case the script detects a non Linux system:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $OS$

set $OS$ = GetOS

if not($OS$ = "Linux")
        LogError "Wrong OS: Product: " + $ProductId$ + "is only for Linux"
        isFatalError "Wrong OS"
endif

Example: detecting the distribution type:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $distrotype$

set $distrotype$ = getLinuxDistroType

if $distrotype$ = 'debian'
        ShellInAnIcon_Upgrade_deb
else
        LogError "Wrong Distro: This Product is for Debian/Ubuntu only"
        isFatalError "Wrong distro"
endif

if not("0" = getLastExitCode)
        Message "failed ShellInAnIcon_Upgrade"
        LogError "failed ShellInAnIcon_Upgrade"
        isFatalError "failed Upgrade"
endif


[ShellInAnIcon_Upgrade_deb]
set -x
export DEBIAN_FRONTEND=noninteractive
apt-get --yes install aptitude
apt-get update
apt-get --yes dist-upgrade
exit $?

Example: detecting the Linux version and installing a packet:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $distCodeName$
DefVar $distroName$
DefVar $distRelease$
DefVar $desktop$

DefStringList $linuxInfo$

set $linuxInfo$ = getLinuxVersionMap
set $distCodeName$ = getValue("Codename", $linuxInfo$)
set $distRelease$ = getValue("Release", $linuxInfo$)
set $distroName$  = getValue("Distributor ID", $linuxInfo$)

set $desktop$ = GetProductProperty("desktop", "kde")


if $distrotype$ = 'suse'
        if $desktop$ = "unity"
                Message " No Unity on SUSE - fallback to KDE ..."
                set $desktop$ = "kde"
        endif ; unity


        if $desktop$ = "kde"
                if ($distroName$ = 'openSUSE project')
                        ShellInAnIcon_kde_suse
                endif
                if ("SUSE LINUX" = $distroName$) and ($distRelease$ = "11")
                        ShellInAnIcon_kde_sles11
                endif
                if not("0" = getLastExitCode)
                        LogError "failed ShellInAnIcon"
                        Message "failed kde"
                        isFatalError "failed kde"
                endif
        endif ; kde
endif; suse type

[ShellInAnIcon_kde_suse]
set -x
zypper --no-gpg-checks --non-interactive install patterns-openSUSE-kde4 patterns-openSUSE-kde4_basis
zypper --no-gpg-checks --non-interactive install splashy-branding-openSUSE
exit $?

[ShellInAnIcon_kde_sles11]
set -x
zypper --no-gpg-checks --non-interactive install --auto-agree-with-licenses -t pattern kde
exit $?

Example: adding a repository:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $distCodeName$
DefVar $distroName$
DefVar $distRelease$
DefVar $desktop$

DefStringList $linuxInfo$

set $linuxInfo$ = getLinuxVersionMap
set $distCodeName$ = getValue("Codename", $linuxInfo$)
set $distRelease$ = getValue("Release", $linuxInfo$)
set $distroName$  = getValue("Distributor ID", $linuxInfo$)

set $desktop$ = GetProductProperty("desktop", "kde")


if $distroName$ = 'Ubuntu'

        if $desktop$ = "cinnamon"
                set $desktopPackage$ = $desktop$
                ShellInAnIcon_ubuntu_cinnamon
                if not("0" = getLastExitCode)
                        Message "failed ShellInAnIcon_ubuntu_cinnamon"
                        LogError "failed ShellInAnIcon_ubuntu_cinnamon"
                        isFatalError "failed cinnamon"
                endif
        endif ; cinnamon
endif; ubuntu

[ShellInAnIcon_ubuntu_cinnamon]
set -x
export DEBIAN_FRONTEND=noninteractive
# we need to get the add-apt-repository command
apt-get --yes --force-yes install python-software-properties
# the cinnamon repository
add-apt-repository ppa:gwendal-lebihan-dev/cinnamon-stable
apt-get update
apt-get --yes install ubuntu-desktop
exit $?

9.6. Linux localboot products

Here some localboot products that are part of the standard opsi Linux support.

9.6.1. l-os-postinst

This product installs and configures those parts of the base installation, that cannot be done from the bootimage in a proper way.

This is for the different distributions:

  • Fedora / CentOS:

    • installation of se-linux
  • Fedora:

    • installation of se-linux

This product has a dependency to the product l-system-update which is executed before running l-os-postinst.
This product has a high priority, so it is executed before common products.

9.6.2. l-desktop

The product l-desktop installs a desktop packet on the computer.

The property desktop selects the desktop to be installed. Not all of the desktops are available for every distribution. For instance Unity is available for Ubuntu only. If the selected desktop is not available, the distribution specific default desktop will be installed. Furthermore the scope of the desktop packets differs according to the distribution and the selected desktop. It can be just the actual desktop software, or might also contain some base products like libreoffice, firefox, PDF Reader etc.

The property desktop can have the following values:

  • Gnome
    Default for Debian, Fedora, CentOS, RHEL.
    Available for all distributions.
  • KDE
    Default für SLES, OpenSuse. Available for all distributions.
  • Unity
    Available for Ubuntu only.
  • Cinnamon
    Available for Ubuntu only.
  • xfce4
    Available for Ubuntu, Debian, Fedora.
  • lxde
    Available for Ubuntu, Debian.

9.6.3. l-system-update

This product updates the system.

9.6.4. l-swaudit

Software inventory, based on the packet manager

9.6.5. l-hwaudit

Hardware inventory.
The hardware inventory currently is based on the Python implemented method as also used by the bootimage. Therefore the packet python-opsi from the opsi-repository of the distribution must be installed. So if there is no opsi-repository available for this distribution, the hardware inventory fails.

9.6.6. l-jedit

Java based editor with syntax highlighting for opsi-script. If Java is missing on the system, it will be installed automatically.

9.7. Inventory

To create an inventory, the data are collected on the client and sent to the server. The hardware inventory is based on the methods implemented in the bootimage.

The software inventory is based on the data from the packet management of the deployed Linux distribution.

9.8. UEFI / GPT support

With opsi 4.0.5 an increasing number of Linux products are UEFI/GPT compatible. For details refer to the list of netboot products above.

9.9. Roadmap

Linux support is a brand new opsi feature. Therefore not all of the planned features have been implemented yet with the first release.
Planned features to follow are:

  • opsiclientd Linux port
  • configurable partitioning
  • logical volume management
  • patching XML- and JSON files
  • patching hierarchical configuration files like dhcpd.conf

Chapter 10. opsi with UEFI / GPT

10.1. Preconditions for working with UEFI / GPT

This module currently is a co-funded opsi extension.
Some preconditions are required to work with that module, which is to get a suitable modules file to unlock the feature. You can get this unlock file by purchasing the extension module. For evaluation you can get a time limited modules unlock file without charge. ( → mail to info@uib.de).

Technical requirements are opsi 4.0.5 with packet versions:

Table 10.1. required packets

opsi packetversion

Netboot products

>=4.0.5

opsi server packets

>=4.0.5


10.2. Introduction

Recent PCs, tablets and server often are equpped with an UEFI BIOS. Often there is a legacy mode available to support the old features including PXE boot. But more and more devices come with an UEFI only BIOS (especially tablets). So they cannot be managed with the previous opsi environment.

To integrate these devices into opsi and to be able to use the advantages of UEFI, the uib gmbh developed the opsi extension for UEFI support.

10.3. What is UEFI and what is different about it?

UEFI is the abbreviation of Unified Extensible Firmware Interface and is the follow-up to the classic PC-BIOS (MBR-BIOS).

For detailled information on UEFI there are some links listed below.

UEFI has much more features than the old BIOS. Basically UEFI is a small operating system by itself. But in this place, we just consider some features, that are of special interes to the system administrator:

  • The recent (by January 2014) implementations of UEFI by the hardware manufacturers have not developed any clear standards yet. As soon as the system is to be booted from any other device but the hard disc, you face the utter chaos. Often UEFI and classic BIOS are implemented both, sometimes they can be deactivated individually, or sometimes not. UEFI can be implemented with the Compatibility Support Module (CSM), or without. Netboot might work, or might not.
    Especially the availability of netboot is essential for structurd client management.
  • With the classic PC-BIOS the BIOS and its configuration usually are separated from the operating system. So BIOS configurations like the boot sequence cannot be changed by the operating system.
    This is different with UEFI. The operating system can change the boot sequence (and usually it does). This has consequences for a client management that relies on netboot.
  • The UEFI Bios comes with its own boot manager, which not only can be used by the operating systems to change the boot sequence, but also contains the start entries for the operating systems themselves. This is to support the parallel installation of different operating systems, so that there is no conflict with the different boot loaders.
  • The UEFI BIOS can be implemented for 32 or 64 bit, which also presets a 32 or 64 bit operating system. So there cannot be installed a 32 bit OS on a 64 bit UEFI system.
  • Secureboot (not supported yet by opsi)
  • partitioning with GPT and additional partitions for the bootloader:

    • 1. partition: EFI system partition (ESP) 100 - 260 MByte ; VFAT
    • 2. partition: Microsoft reserved (MSR) 32 - 128 MB; NTFS
    • following the actual OS partitions

Links :

http://de.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

10.4. What is different about GPT

GPT (GUID Partition Table) id the follow-up for the previous MBR partition tables. GPT is part of the UEFI specification.

The main features for the sysadmin are
  • overriding the 2 Terabyte limit (now it is 8 Zebibyte)
  • almost unlimited number of primary partitions
  • changed partition types / GUIDs
  • new: partition GUIDs
  • new: partition attributes (hidden, read only, …)
  • different tools: gdisk

Basically GPT can be used without UEFI. But UEFI depends on GPT. With UEFI there are up to two additional partitions:

  1. the EFI system partition (ESP) with the bootloaders
  2. Microsoft reserved (MSR)

Links :

http://de.wikipedia.org/wiki/GUID_Partition_Table

10.5. UEFI Boot

In contrary to the old BIOS the boot sequence not only can be defined for devices, but also can be set for different bootloaders on the EFI system partition. Furthermore the sequence can be changed by a running operating system. So if you set netboot as the first boot priority, this setting will not survive the first OS installation.

10.6. UEFI Netboot

Unfortunately early UEFI implementations do not support netboot at all, but netboot support is increasing.

Meanwhile there are a lot of UEFI bootloader (like grub2 or elilo), but mostly without netboot support.

With the UEFI support extension module uib gmbh has developed a succesfull UEFI netboot support for integrating UEFI clients into opsi. Because the UEFI standard is still under development and changing, in future the opsi UEFI module will continue to adapt to the technical changes, which might require structural redesigns of the module.

10.7. opsi support for UEFI netboot

The opsi support for UEFI is based on several components:

  • adaption of the netboot UEFI bootloader ELILO to the opsi / client-management requirements.
  • new opsipxeconfd, which also supports config files for the opsi-ELILO (in addition to the PXE config).
  • new (64 bit) opsi-linux-bootimage with the tools for UEFI- and GPT management
  • redesigned netboot products for OS installation (Windows/Linux) with additional support of UEFI/GPT (of course only for OS that support UEFI).
  • client setting on the opsi-server whether to be treated as UEFI client or not. (clientconfig.dhcpd.filename=linux/pxelinux.cfg/elilo.efi)
  • support of a software triggered switch to UEFI netboot.
    The label of the UEFI netboot entry of the Bios can be saved on the opsi-server (clientconfig.uefinetbootlabel), as far as the BIOS supports it (so there is an activatable netboot entry in the Bios). This allows opsi-product to enbale netboot selective for the next reboot. This technique is implemented in several opsi products. An important example is the product opsi-uefi-netboot:
    This product tries to configure the Bios for netboot and then triggers a reboot. If there is no uefinetbootlabel or it is a non UEFI client, just a reboot is triggered.
    This product is available for Windows and for Linux.

10.8. Installation

All packets required are installed automatically with opsi version 4.0.5.

10.9. Configuration of the DHCP server

Configuration example of a Linux isc-dhcp-server:

filename "linux/pxelinux.0";

# this is the UEFI detection:
if substring (option vendor-class-identifier , 19,1 ) = "0" {
        log (info, "pxe client");
        filename "linux/pxelinux.0";
}
else if substring (option vendor-class-identifier , 19,1 ) = "6" {
        log (info, "efi32 client");
        filename "linux/pxelinux.cfg/elilo32.efi";
}
else if substring (option vendor-class-identifier , 19,1 ) = "7" {
        log (info, "efi64 client");
        filename "linux/pxelinux.cfg/elilo.efi";
}
else {
        log (info, concat ( "Unhandled vendor class Arch: ", substring (option vendor-class-identifier , 19,1 )));
}

http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/s1-netboot-pxe-config.html

10.10. Criteria for a good BIOS

Whether an UEFI BIOS meets the requirements of a client management system like opsi depends on several criteria. These criteria do not estimate the qualitiy of the device, but only whether it can be managed by using netboot. This requires BIOS functions for UEFI netboot. Hier an example comparison:

Table 10.2. Example for UEFI BIOS differences

 Lenovo TwistMS-SurfaceDell Venue 11

UEFI pure

UEFI + CSM

x

Legacy

x

Both

x

x

UEFI Netboot

activatable entry

x

netboot without interaction

x


In this case activatable entry means, that for the next reboot a netboot can be activated by standard software. netboot without interaction means, that an activated netboot will be executed at the next reboot without any require4d interaction (like pressing any key combinations, F12 key, …). If these preconditions are met, special opsi products can trigger a netboot. This feature is very important for automated processing. A product using this feature is for instance the localboot product for Windows and Linux opsi-uefi-netboot.

10.11. Technical details

The following sub chapters provide some information for scripted or manual handling of UEFI / GPT. For understanding how opsi works with UEFI/GPT, knowing these details is not required.

10.11.1. Technichal details about UEFI

UEFI Bootloader entries can be managed on Linux with the program efibootmgr.
List of boot entries:

efibootmgr -v
BootCurrent: 000D
Timeout: 0 seconds
BootOrder: 0012,0011,000D,0010,000B,0009,0007,0008,000A,000C
Boot0000  Setup
Boot0001  Boot Menu
(..)
Boot0007* USB CD        030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0008* USB FDD       030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0009* ATA HDD0      030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000D* PCI LAN       030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot0010* ubuntu        HD(1,800,31801,faffb7b9-bdf9-4767-b475-0b8aee68d3ac)File(\EFI\ubuntu\grubx64.efi)
Boot0011* opsitempwinpe HD(4,3c72800,7cf801,dc1cea68-a296-4fb8-a97a-263227ed86f4)File(\EFI\boot\bootx64.efi)
Boot0012* Windows Boot Manager  HD(1,800,31801,5e4ffde2-3e25-42dd-b0f7-fcb7ee5d2b20)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................

On Windows UEFI boot loader entries can be managed with the program bcdedit.
List of boot entries:

bcdedit /enum firmware

Start-Manager für Firmware
- - - - - - - - - - - - - - -
Bezeichner              {fwbootmgr}
displayorder            {bootmgr}
                        {99a9f9be-9a98-11e3-b22f-806e6f6e6963}
                        {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4}
                        {11a8b986-99df-11e3-ae5c-b888e3e3cbb4}
Windows-Start-Manager
- - - - - - - - - - - - - - -
Bezeichner              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\bootmgfw.efi
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b971-99df-11e3-ae5c-b888e3e3cbb4}
description             Setup
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b972-99df-11e3-ae5c-b888e3e3cbb4}
description             Boot Menu
(...)
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b978-99df-11e3-ae5c-b888e3e3cbb4}
description             USB CD
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b979-99df-11e3-ae5c-b888e3e3cbb4}
description             USB FDD
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b97a-99df-11e3-ae5c-b888e3e3cbb4}
description             ATA HDD0
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4}
description             PCI LAN
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {99a9f9be-9a98-11e3-b22f-806e6f6e6963}
device                  partition=X:
path                    \EFI\boot\bootx64.efi
description             opsitempwinpe

Mit beiden Programmen lassen sich Einträge erstellen, löschen, der nextboot setzen und die Reihenfolge manipulieren.

Beispiel: Eintrag für den nächsten Boot setzen:

Linux

efibootmgr /bootnext <hexId>

Windows

bcdedit /set {fwbootmgr} bootsequence <GUID>

10.11.2. Technichal details about GPT

GPT partitions know some new partition types. These are derived from the standard types. So the partition type for NTFS 07 becomes GPT 0700. The Linux partition types 82 and 83 become 8200 and 8300.

The list of known partition types can be shown:

# sgdisk -L
0700 Microsoft basic data  0c01 Microsoft reserved    2700 Windows RE
4100 PowerPC PReP boot     4200 Windows LDM data      4201 Windows LDM metadata
7501 IBM GPFS              7f00 ChromeOS kernel       7f01 ChromeOS root
7f02 ChromeOS reserved     8200 Linux swap            8300 Linux filesystem
8301 Linux reserved        8302 Linux /home           8400 Intel Rapid Start
8e00 Linux LVM             a500 FreeBSD disklabel     a501 FreeBSD boot
a502 FreeBSD swap          a503 FreeBSD UFS           a504 FreeBSD ZFS
a505 FreeBSD Vinum/RAID    a580 Midnight BSD data     a581 Midnight BSD boot
a582 Midnight BSD swap     a583 Midnight BSD UFS      a584 Midnight BSD ZFS
a585 Midnight BSD Vinum    a800 Apple UFS             a901 NetBSD swap
a902 NetBSD FFS            a903 NetBSD LFS            a904 NetBSD concatenated
a905 NetBSD encrypted      a906 NetBSD RAID           ab00 Apple boot
af00 Apple HFS/HFS+        af01 Apple RAID            af02 Apple RAID offline
af03 Apple label           af04 AppleTV recovery      af05 Apple Core Storage
be00 Solaris boot          bf00 Solaris root          bf01 Solaris /usr & Mac Z
bf02 Solaris swap          bf03 Solaris backup        bf04 Solaris /var
bf05 Solaris /home         bf06 Solaris alternate se  bf07 Solaris Reserved 1
bf08 Solaris Reserved 2    bf09 Solaris Reserved 3    bf0a Solaris Reserved 4
bf0b Solaris Reserved 5    c001 HP-UX data            c002 HP-UX service
ea00 Freedesktop $BOOT     eb00 Haiku BFS             ed00 Sony system partitio
ef00 EFI System            ef01 MBR partition scheme  ef02 BIOS boot partition
fb00 VMWare VMFS           fb01 VMWare reserved       fc00 VMWare kcore crash p
fd00 Linux RAID

Actually the partition types shown in this list are just short forms for the actual GUIDs that are used. The partition schema is named after that.

So: 0700 stands for Microsoft basic data and for the GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

A list of GUIDs can be found at Wikipedia:

https://de.wikipedia.org/wiki/GUID_Partition_Table#Partitionstyp-GUIDs

https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

Furtheron the tool gdisk (and sgdisk, …) has an internal substitution table for unknown partition types. For the old partion type for vfat32 0b there is no corresponding 0b00. By passing the type 0b00 to sgdisk, it will be translated to 0700 without any message. Perhaps because of the consideration: vfat32 - this must be some Microsoft data partition …

GPT partitionen can have attributes.

List of the currently known attributes

Value

Description

Attribute value (sgdisk --info / diskpart gpt attribute)

nix

nix

0000000000000000

0

system partition

0000000000000001

1

partition hidden from EFI

0000000000000002

2

legacy boot flag (legacy BIOS bootable)

0000000000000004

60

read-only

1000000000000000

62

hidden

4000000000000000

63

do not automount

8000000000000000

On Linux the attributes can be set with sgdisk by the option -A, --attributes and using the short form. On Windows they can be set with diskpart by the command gpt attributes and using the long form.

Examples:

select disk 0
select partition 1
gpt attributes=0x0000000000000000
sgdisk -t 1:0700 --attributes 1:clear:63 --attributes 1:set:62 -p /dev/sda

show the partition table with -p , --print:

sgdisk -p /dev/sda

show detailled infos for a partition (1) with --info=:

sgdisk --info=1 /dev/sda

10.11.3. opsi UEFI/GPT Roadmap

  • UEFI 32 Bit support
  • other netboot capable UEFI boot loader (grub2)
  • Secureboot

Chapter 11. opsi Extension opsi-clonezilla

11.1. Preconditions for the opsi Extensions opsi-clonezilla

Technical preconditions are opsi 4.0.3 with the following package and product versions:

Table 11.1. Needed product and package versions

opsi-PaketVersion

opsi-linux-bootimage

>= 20130207-1


or opsi 4.0.5 with the following package and product versions:

Table 11.2. Needed product and package versions

opsi packetversion

opsi-linux-bootimage

>= 20140805-1

opsi-clonezilla

>= 4.0.5-1


11.2. Introduction

Besides of the packet based (unattended) installation, opsi had in the past just a rudimental support for image based installations. With integrating the technique of the Open Source product clonezilla (http://clonezilla.org/) into opsi, now a comprehensive and flexible solution for handling partition and disc images is available.

11.3. Concept

We have combined the clonezilla scrips with the opsi-linux-bootimage to generate the following benefits:

  • integration into the opsi process control
  • automated mount of the shares for the image repository
  • availability of automated processing

11.4. Interactive Proceedings

Starting the opsi-clonezilla per default starts in the interactive mode. This interactive mode allows to choose the desired operations and parameters easily. Knowing the commands and their parameters from this makes it easy to create non-interactive run commands from this.

  • Set for the property imageshare a share as value. This share should have the format //server/share. Please note the use of slashes instead of back slashes. This share should be mountable by the opsi user pcpatch with the password as known by the opsi-server. This is normally the share opsi_images from the opsi-server.
  • Switch the property runcommand to /opt/drbl/sbin/ocs-live or ocs-live using opsi >= 4.0.5. This is the interactive mode of clonezilla.
  • Start the netboot product.
  • At the first dialog you will be asked, whether anything should be mounted to /home/partimg. Choose Skip because the mount has already be done by the opsi bootimage.

Figure 11.1. Skip: The share given by the property imageshare will be mounted by the bootimage to /home/partimg.

../images/clonezilla_skip.png

The mounted partition will be displayed:

Figure 11.2. Mounted partitions.

../images/clonezilla_existing_setting.png

By choosing Expert or Beginner you decide if you want to use all default parameters or have the possibility to modify them.

If you have opsi version less than 4.0.5 it is a good idea to choose Expert in order to be able to change parameters for non-interactive use.

Since opsi 4.0.5 you may also choose the Beginner mode.

Figure 11.3. Expert or Beginner ?

../images/clonezilla_expert.png

Now you have to choose which basic operation you like to run. In this manual we discuss only the following operations:

  • save disk
  • save partition
  • restore disk
  • restore partition

Figure 11.4. Choose operation.

../images/clonezilla_select_mode.png

11.4.1. Interactive savedisk in the expert mode

Here we show (as an example for similar operations) the additional dialogs you will get in the savedisk expert mode.

Figure 11.5. Choose the tools (default value recommended)

../images/clonezilla_tool-priority.png

Figure 11.6. miscellaneous: unset -c here to suppress interactive questions for automation.

../images/clonezilla_parameters1.png

Figure 11.7. compression method before opsi 4.0.5, which is bootimages ⇐ 20130207 (opsi-clonezilla_2.01-3), select here -z1. With opsi 4.0.5 and above not required anymore.

../images/clonezilla_compression.png

Figure 11.8. Check filesystem (den default skip nutzen)

../images/clonezilla_parameter4.png

Figure 11.9. Check the saved image (den default yes nutzen)

../images/clonezilla_parameter5.png

Figure 11.10. Action after cloning (use the default -p true, the reboot is triggered by the opsi bootimage).

../images/clonezilla_parameters6.png

11.4.2. Interactive savedisk

Figure 11.11. Name for the image to be saved on disc.

../images/clonezilla_imagename.png

Figure 11.12. Select the disc to create the image from

../images/clonezilla_choose_disk.png

Figure 11.13. The resulting command. This can be set as product property runcommand

../images/clonezilla_savedisk_command.png

Figure 11.14. Progress bar

../images/clonezilla_savedisk_progress.png

11.4.3. Interactive savepart

Figure 11.15. Name for the partition image to be saved as.

../images/clonezilla_imagename.png

Figure 11.16. Select the partition to create the image from

../images/clonezilla_choosepart.png

Figure 11.17. The resulting command. This can be set as product property runcommand

../images/clonezilla_saveparts_command.png

Figure 11.18. Progress bar

../images/clonezilla_savepart_progress.png

11.4.4. Interactive restoredisk

Figure 11.19. Selct the disc image to be restored

../images/clonezilla_choose_diskimage2restore.png

Figure 11.20. Select the disc where the image is to be restored to

../images/clonezilla_choose_restore_targetdisk.png

Figure 11.21. The resulting command. This can be set as product property runcommand

../images/clonezilla_restoredisk_command.png

Figure 11.22. Query before starting to overwrite the disc. Can be supressed by omitting the option -c from the command.

../images/clonezilla_restoredisk_askbeforeinst.png

Figure 11.23. Progress bar

../images/clonezilla_restoredisk_progress.png

11.4.5. Interactive restorepart

Figure 11.24. Select the partimage to be restored

../images/clonezilla_choose_partimage2restore.png

Figure 11.25. Select the partition where the image is to be restored to.

../images/clonezilla_choose_restore_targetpart.png

Figure 11.26. Query before starting to overwrite the disc. Can be supressed by omitting the option -c from the command.

../images/clonezilla_restorepart_askbeforeinst.png

Figure 11.27. Progress bar

../images/clonezilla_restorepart_progress.png

11.5. Not interactive processes

By setting the desired command as the product property runcommand opsi-clonezilla is switched to the non interactive mode.

  • Set the property imageshare to a share, that can be mounted by the user pcpatch with the password as known by the opsi-server. The format for the share is //server/share (attention: use forward slashes, not backward slashes).
  • Set the property runcommand to the non interactive command.

Here are some non interactive versions of the examples from above (without -c and with --batch). Since opsi 4.0.5 the parameter -z1 can be omitted. This accelerates the compression with multi processor kernels:

  • /opt/drbl/sbin/ocs-sr --batch -q2 -j2 -rm-win-swap-hib -z1 -i 2000 -p true savedisk 2014-06-11-12-img sda
  • /opt/drbl/sbin/ocs-sr --batch -q2 -j2 -rm-win-swap-hib -z1 -i 2000 -p true saveparts partimg sda1
  • /opt/drbl/sbin/ocs-sr --batch -g auto -e1 auto -e2 -r -j2 -p true restoredisk 2014-06-11-12-img sda
  • /opt/drbl/sbin/ocs-sr --batch -g auto -e1 auto -e2 -r -j2 -k -p true restoreparts partimg sda1

Furthermore in these examples the image names 2014-06-11-12-img or partimg can be replaced by the string imagefile. In this case the string imagefile will be substituted by the value of the property imagefile.

11.6. opsi-clonezilla known bugs

At opsi-clonezilla version 4.0.5-2 with bootimage Version 20140819-1 there are problems while imaging computers that running in UEFI mode.

11.7. Clonezilla command reference

http://clonezilla.org/clonezilla-live-doc.php

http://allthatnetwork.blogspot.de/2012/10/clonezilla-ocs-sr-options.html

Clonezilla ocs-sr options
Setting the TERM as linux
/opt/drbl/sbin/ocs-sr: -h: invalid option
Usage:
To save or restore image
ocs-sr [OPTION] {savedisk|saveparts|restoredisk|restoreparts} IMAGE_NAME DEVICE
 Options for saving:
-fsck-src-part, --fsck-src-part
Run fsck interactively on the source file system before saving it.
-fsck-src-part-y, --fsck-src-part-y
Run fsck automatically on the source file system before saving it. This option will always attempt to fix any detected filesystem corruption automatically. //NOTE// Use this option in caution.
-gm, --gen-md5sum
Generate the MD5 checksum for the image. Later you can use -cm|--check-md5sum option to check the image when restoring the image. Note! It might take a lot of time to generate if the image size is large.
-gs, --gen-sha1sum
Generate the SHA1 checksum for the image. Later you can use -cs|--check-sha1sum option to check the image when restoring the image. Note! It might take a lot of time to generate if the image size is large.
-j2, --clone-hidden-data
Use dd to clone the image of the data between MBR (1st sector, i.e. 512 bytes) and 1st partition, which might be useful for some recovery tool.
-ntfs-ok, --ntfs-ok
Assume the NTFS integrity is OK, do NOT check again (for ntfsclone only)
-rm-win-swap-hib, --rm-win-swap-hib
Try to remove the MS windows swap file in the source partition.
-q, --use-ntfsclone
If the partition to be saved is NTFS, use program ntfsclone instead of partimage (i.e. Priority: ntfsclone > partimage > dd)
-q1, --force-to-use-dd
Force to use dd to save partition(s) (inefficient method, very slow, but works for all the file system).
-q2, --use-partclone
Use partclone to save partition(s) (i.e. partclone > partimage > dd).
-rescue, --rescue
Turn on rescue mode, i.e. try to skip bad sectors.
-sc, --skip-check-restorable
By default Clonezilla will check the image if restorable after it is created. This option allows you to skip that.
-z0, --no-compress
Don’t compress when saving: very fast but very big image file (NOT compatible with multicast restoring!!!)
-z1, --gzip-compress
Compress using gzip when saving: fast and small image file (default)
-z1p, --smp-gzip-compress
Compress using parallel gzip program (pigz) when saving: fast and small image file, good for multi-core or multi-CPU machine
-z2, --bz2-compress
Compress using bzip2 when saving: slow but smallest image file
-z2p, --smp-bzip2-compress
Compress using parallel bzip2 program (pbzip2) when saving: faster and smallest image file, good for multi-core or multi-CPU machine
-z3, --lzo-compress
Compress using lzop when saving: similar to the size by gzip, but faster than gzip.
-z4, --lzma-compress
Compress using lzma when saving: slow but smallest image file, faster decompression than bzip2.
-z5, --xz-compress
Compress using xz when saving: slow but smallest image file, faster decompression than bzip2.
-z5p, --smp-xz-compress
Compress using parallel xz when saving: slow but smallest image file, faster decompression than bzip2.
-z6, --lzip-compress
Compress using lzip when saving: slow but smallest image file, faster decompression than bzip2.
-z6p, --smp-lzip-compress
Compress using parallel lzip when saving: slow but smallest image file, faster decompression than bzip2.
-z7, --lrzip-compress
Compress using lrzip when saving.
-i, --image-size SIZE
Set the split image file volume size SIZE (MB). When ocs-sr is run with -x, the default SIZE is set as 2000, if without -x, we will not split it.

Three words are reserved for IMAGE_NAME, "ask_user" is used to let user to input a name when saving an image. "autoname" is used to automatically generate the image name based on network card MAC address and time. "autohostname" is used to automatically generate the image name based on hostname.

A word is reserved for DEVICE, "ask_user" could be used to let user to select the source device when saving an image.

Options for restoring:
-g, --grub-install GRUB_PARTITION
Install grub in the MBR of the disk containing partition GRUB_PARTITION with root grub directory in the same GRUB_PARTITION when restoration finishs, GRUB_PARTITION can be one of "/dev/hda1", "/dev/hda2"… or "auto" ("auto" will let clonezilla detect the grub root partition automatically). If "auto" is assigned, it will work if grub partition and root partition are not in the same partition.
-r, --resize-partition
Resize the partition when restoration finishes, this will try to fix the problem when small partition image is restored to larger partition. Warning!!! Use this carefully… Backup your data first
-k, --no-fdisk, --no-create-partition
Do NOT create partition in target harddisk. If this option is set, you must make sure there is an existing partition table in the current restored harddisk. Default is to create the partition table.
-icrc, --icrc
Skip Partclone CRC checking.
-irhr, --irhr
Skip removing the Linux udev hardware records on the restored GNU/Linux.
-ius, --ius
Skip updating syslinux-related files on the restored GNU/Linux.
-icds, --ignore-chk-dsk-size-pt
Skip checking destination disk size before creating the partition table on it. By default it will be checked and if the size is smaller than the source disk, quit.
-k1,
Create partition table in the target disk proportionally.
-k2,
Enter command line prompt to create partition table manually before restoring image.
-t, --no-restore-mbr
Do NOT restore the MBR (Mater Boot Record) when restoring image. If this option is set, you must make sure there is an existing MBR in the current restored harddisk. Default is Yes
-u, --select-img-in-client
Input the image name in clients
-e, --load-geometry
Force to use the saved CHS (cylinders, heads, sectors) when using sfdisk
-e1, --change-geometry NTFS-BOOT-PARTITION
Force to change the CHS (cylinders, heads, sectors) value of NTFS boot partitoin after image is restored. NTFS-BOOT-PARTITION can be one of "/dev/hda1", "/dev/hda2"… or "auto" ("auto" will let clonezilla detect the NTFS boot partition automatically)
-e2, --load-geometry-from-edd
Force to use the CHS (cylinders, heads, sectors) from EDD (Enhanced Disk Device) when creating partition table by sfdisk
-y, -y0, --always-restore, --always-restore-default-local
Let Clonezilla server as restore server, i.e. client will always has restore mode to choose (However default mode in PXE menu is local boot)
-y1, --always-restore-default-clone
Let Clonezilla server as restore server, i.e. client will always has restore mode to choose (The default mode in PXE menu is clone, so if client boots, it will enter clone always, i.e. clone forever)
-j, --create-part-by-sfdisk
Use sfdisk to create partition table instead of using dd to dump the partition table from saved image (This is default)
-j0, --create-part-by-dd
Use dd to dump the partition table from saved image instead of sfdisk. ///Note/// This does NOT work when logical drives exist.
-j1, --dump-mbr-in-the-end
Use dd to dump the MBR (total 512 bytes, i.e. 446 bytes (executable code area) + 64 bytes (table of primary partitions) + 2 bytes (MBR signature; # 0xAA55) = 512 bytes) after disk image was restored. This is an insurance for some hard drive has different numbers of cylinder, head and sector between image was saved and restored.
-j2, --clone-hidden-data
Use dd to clone the image of the data between MBR (1st sector, i.e. 512 bytes) and 1st partition, which might be useful for some recovery tool.
-hn0 PREFIX
Change the hostname of M$ Windows based on the combination of hostname prefix and IP address, i.e. PREFIX-IP
-hn1 PREFIX
Change the hostname of M$ Windows based on the combination of hostname prefix and NIC MAC address, i.e. PREFIX-MAC
--max-time-to-wait TIME
When not enough clients have connected (but at least one), start anyways when TIME seconds since first client connection have pased. This option is used with --clients-to-wait
-cm, --check-md5sum
Check the MD5 checksum for the image. To use this option, you must enable -gm|--gen-md5sum option when the image is saved. Note! It might take a lot of time to check if the image size is large.
-cs, --check-sha1sum
Check the SHA1 checksum for the image. To use this option, you must enable -gs|--gen-sha1sum option when the image is saved. Note! It might take a lot of time to check if the image size is large.
--mcast-port NO
Assign the udp port number for multicast restore. This is used by clonezilla server. Normally it’s not necessary to manually assign this option.

A word is reserved for IMAGE_NAME, "ask_user" is used to let user to input a name when saving an image.

A word is reserved for DEVICE, "ask_user" could be used to let user to select the source device when saving an image.

General options:
-l, --language INDEX
Set the language to be shown by index number:
[0|en_US.UTF-8]: English,
[1|zh_TW.BIG5]: Traditional Chinese (Big5) - Taiwan,
[2|zh_TW.UTF-8]: Traditional Chinese (UTF-8, Unicode) - Taiwan
[a|ask]: Prompt to ask the language index
-b, -batch, --batch
(DANGEROUS!) Run program in batch mode, i.e. without any prompt or wait for pressing enter key. //NOTE// You have to use -batch instead of -b when you want to use it in the boot parameters. Otherwise the program init on system will honor -b, too.
-c, --confirm
Wait for confirmation before saving or restoring
-d, --debug-mode
Enter command mode to debug before saving/restoring
--debug=LEVEL
Output the partimage debug log in directory /var/log/ with debug LEVEL (0,1,2… default=0)
-m, --module MODULE
Force to load kernel module MODULE, this is useful when some SCSI device is not detected. NOTE! Use only one module, more than one may cause parsing problem.
-o0, --run-prerun-dir
Run the script in the direcoty /opt/drbl/share/ocs/postrun before clone is started. The command will be run before MBR is created or saved.
-o1, -o, --run-postrun-dir
Run the script in the direcoty /opt/drbl/share/ocs/postrun when clone is finished. The command will be run before that assigned in -p or --postaction.
-w, --wait-time TIME
Wait for TIME secs before saving/restoring
--nogui
Do not show GUI of partimage, use text only
-a, --no-force-dma-on
Do not force to turn on HD DMA
-mp, --mount-point MOUNT_POINT
Use NFS to mount MOUNT_POINT as directory ocsroot (ocsroot is assigned in drbl.conf)
-or, --ocsroot DIR
Specify DIR (absolute path) as directory ocsroot (i.e. overwrite the ocsroot assigned in drbl.conf)
-p, --postaction [choose|poweroff|reboot|command|CMD]
When save/restoration finishs, choose action in the client, poweroff, reboot (default), in command prompt or run CMD
-ns, --ntfs-progress-in-image-dir
Save the ntfsclone progress tmp file in the image dir so that if cloning is in DRBL client, the progress can be check in the server (Default in to be put in local /tmp/, which is local tmpfs).
-um, --user-mode [beginner|expert]
Specify the mode to use. If not specified, default mode is for a beginner.
-v, --verbose
Prints verbose information
-d0, --dialog
Use dialog
-d1, --Xdialog
Use Xdialog
-d2, --whiptail
Use whiptail
-d3, --gdialog
Use gdialog
-d4, --kdialog
Use kdialog
-x, --interactive
Interactive mode to save or restore.

Example:

  • To save or restore image in client (Only that DRBL client will join, and its local partitions is NOT mounted). NOTE!!! You should run the command in DRBL client or you have to make sure the target device is NOT busy!.
  • To save all the data in local first IDE harddrive hda as image IMAGE1, use ntfsclone instead of partimage, and lzop compression (NOTE!!! You should run the command in DRBL client or make sure hda is NOT busy/mounted!):
    ocs-sr --use-ntfsclone -z3 savedisk IMAGE1 hda
  • To save the data in first and second partitions in local first IDE harddrive hda as image IMAGE2, use ntfsclone instead of partimage, and lzop compression (NOTE!!! You should run the command in DRBL client, or make sure hda is NOT busy/mounted!):
    ocs-sr --use-ntfsclone -z3 saveparts IMAGE2 "hda1 hda2"
  • To restore image IMAGE1 to local hda. grub-install will be run after cloning (image IMAGE1 is already in DRBL server. NOTE!!! You should run the command in DRBL client or make sure hda is NOT busy/mounted!):
    ocs-sr -g auto restoredisk IMAGE1 hda
  • To restore image first and second partitions from IMAGE2 to local hda1 and hda2. grub-install will be run after cloning (image IMAGE2 is already in DRBL server. NOTE!!! You should run the command in DRBL client or make sure hda is NOT busy/mounted!):
    ocs-sr -g auto restoreparts IMAGE2 "hda1 hda2"
  • To save disk(s)/partitition(s) as an image or restore an image to disk(s)/partitition(s) interactively, use:
    ocs-sr -x

Chapter 12. opsi extension opsi local image

12.1. Preconditions for the opsi extension opsi local image

This module currently is a cofunding project.
Some preconditions have to be met to use this module. So it requires a special modules file to unlock this feature. This module file can be obtained by buying the extension module. For evaluation we also provide a temporary modules file without charge ( → mail to info@uib.de).

Important

until further notice this extension module can only be used by public authorities (like schools / colleges / universities).

As a technical precondition opsi 4.0.3 is required with the packet versions:

Table 12.1. Required packets

opsi packetversion

opsi-linux-bootimage

>= 20130207-1


12.2. Introduction

Opsi is a good point to start the the automated installation and maintenance of Windows clients - especially when there is heterogenous hardware to be managed. But the opsi standard installation technique based on installation packets is not fast enough to restore class room workstations in short time, like during the break between two classes. So this module is introducing a new concept, by saving the result of the package based installation as an image on a second partition. From this partition the recovery can performed in short time.

  1. Initial installation with mit concluding local image backup
  2. Fast recovery based on different techniques
  3. System maintenance with concluding local image backup
  4. Integration of Linux clients into the Backup/Restore procedure.

12.3. Concept

The requirements of computer networks for education / trainings / class rooms differ from those of other networks. An important requirement, which will be discussed in the following, is the fast recovery of workstations to regain a clean and well known installation status, which has been spoiled by temporary use. This is required for workstations in class rooms, but also for computer pools at universities or any networks for commercial trainings.

The restore must be completed within reliable short time (like the 15 minutes break between two classes) and should also be able to switch the workstations to a differnet base installation (like Win XP / Win 7 / Linux). Also the continuous system maintenance by installing security updates must be included.

opsi is a client management system, that features the packet based installation and maintenance of Windows systems. Its advantage, compared to image based concepts, is especially the handling of heterogenous hardware. The average installation time of two hours is not fast enough to meet the requirements stated above. Image based solutions can be much faster, but also might run into network problems when trying to restore the workstations for a whole class room at once. This problem can be solved by local buffered images. This concept is used for instance by the Linux based system LinBo (Source http://linbo.sourceforge.net/). But even with local buffered images the time limit of 15 minutes might be exceeded because on the hardware in use (like hard disc performance).

Another possible solution would be to lock the system state and redirect all write access to an external container, that can be discarded at system reset. For Linux this approach is used e.g. with FUSE file systems. For windows there exist some commercial products, that can be controlled from the command line and thereby could be used from opsi. But as far as we know, there are no Open Source products available for Windows. So this approach is not available for Open Source solutions.

The resulting solution, that is introduced here, is trying to combine the advantages of the different approaches, to avoid the disadvantages and to provide some scalability to support differing hardware performances. The main features of this combined concept are:

  • Initial Windows installation per PXE boot, packet based with individual driver integration by using the opsi-Linux-Bootimage
  • Storing the result of the initial installation as a backup image on another partition on the local disc by using the opsi-Linux-Bootimage
  • Fast recovery of the installation by using the opsi-Linux-Bootimage
  • Maintenance of the local installation (security updates) by using the opsi system and storing the updated system to the local backup-image by using the opsi-Linux-Bootimage

12.4. Technical Concept

The workstation is being used with a static partition table of three or four partitions.:

  • Partition 1 (System)
    holds the currently installed operating system (Windows / Linux).
    The size of this patition is set during partitioning by the product opsi-local-image-prepare according to the particular property state.
  • Optional: Partition 2 (sysdata)
    These are user data that are to sustain during the restore. The format is NTFS.
    The size of this patition is set during partitioning by the product opsi-local-image-prepare according to the particular property state.
  • Partition 3 (winpe / swap)
    The size of this partition is static and set to 4GB.
    With Windows XP this partition is not used.
    With NT6 (Windows 7) this partition is used during installation for the winpe (which is required for installation) and will not be visible during the operating state of the workstation.
    With Linux this partition is used as swap.
  • Partition 4 (backup)
    This partition is for holding the backup images and their meta data.
    The size of this partition is whatever is left by the other partitions.

The netboot products for the operating system installation use the first two or three partitions (XP the first one only) and do not touch the last partiton. So the backup images on partiton four are still available after installating a new operating system.

12.5. Components

The packet opsi-local-image consists of several components:

The netboot products

  • opsi-local-image-prepare
  • opsi-local-image-winxp
  • opsi-local-image-win7
  • opsi-local-image-win7-x64
  • opsi-local-image-win8
  • opsi-local-image-win8-x64
  • opsi-local-image-win81
  • opsi-local-image-win81-x64
  • opsi-local-image-ubuntu
  • opsi-local-image-backup
  • opsi-local-image-restore
  • opsi-local-image-delete
  • opsi-local-image-capture

The local boot products:

  • opsi-local-image-backup-starter
  • opsi-local-image-sysprep

and an extension of the opsi service methods.

12.5.1. netboot product for partitioning

  • opsi-local-image-prepare
    To create the static partitioning of the hard disc for all other products.
    The property system_partition_size defines the size of partition 1 (Default = 30G)

The property data_partition_size defines the size of the partition 2. When set to 0G, no partition will be created for data (default = 0G).

The property start_os_installation selects a product for installing an operating system and to be started after the partitioning automatically. When installing this product, the product properties imagefile and imagefiles_list of the product opsi-local-image-restore are deleted, for they have become invalid after the repartitioning.

Important

Use this product only for the initial preparation of the disc for it deletes all existing images.

12.5.2. netboot products for installing Windows

The special netboot products for installing Windows are derived from the opsi standard products for windows installation. Therefore the structure and the driver integration are the same as with the standard. For details please refer to the opsi-getting-started manual.

  • opsi-local-image-winxp
    Installation of Windows XP. Uses the first partition only. Administrator password is empty.
  • opsi-local-image-win7
    Installation of Windows7 32 Bit. Administrator password = nt123.
  • opsi-local-image-win7-x64
    Installation of Windows 7 64 Bit. Administrator password = nt123.
  • opsi-local-image-win8
    Installation of Windows 8 32 Bit. Administrator password = nt123.
  • opsi-local-image-win8-x64
    Installation von Windows 8 64 Bit. Administrator password = nt123.
  • opsi-local-image-win81
    Installation von Windows 8.1 32 Bit. Administrator password = nt123.
  • opsi-local-image-win81-x64
    Installation von Windows 8.1 64 Bit. Administrator password = nt123.

The following products have special properties for opsi-local-image:

  • backup_after_install with default value true. In this case this means, that after the OS installation at first the application software is being installed and then an image backup of the installation is generated. Furthermore the value of imageFile of the product opsi-local-image-restore will be deleted. So the generated backup will be named like the current netboot product (e.g. opsi-local-image-win7).
  • setup_after_install
    Here one or more products can be listed, that after the OS installation shall be set to setup. This includes the dependencies of these products.

12.5.3. Netboot products for installing Linux

  • opsi-local-image-ubuntu
    Installation of Ubuntu Linux 12.04/14.04 32Bit/64Bit.
    The installed system has 2 users: root and user. The password for root will be set according to the product property root_password (default: linux123). For user the password will be set according to user_password (default: linux123). Details of the installation can be configured with some product properties. The main product properties are:

    • askbeforeinst:
      Has the start of the installation to be confirmed at the client? (default=true)
    • architecture:
      architecture selection, affects the selection of the bootimage and the installation architecture (default=64bit)
    • additional_packages:
      list of additional packets to be installed, separated by blanks (default = '')
    • language:
      language / locale to be installed (default=de)
    • console_keymap
      keyboard layout to be installed (default=de-latin1-nodeadkeys)
    • timezone:
      timezone to be set (default=Europe/Berlin)
    • online_repository
      the online repository to get the install packets from. Default is http://de.archive.ubuntu.com/ubuntu
    • proxy:
      Proxystring (if required) with following syntax: http://<ip>:<port> (default = '')
    • backup_after_install
      (true/false) default = true. If true, after the installation an image backup will be generated.
    • setup_after_install
      Here one or more products can be listed, that are to be set to setup and so will be installed after the OS installation. This also includes the dependencies of these products.
    • wget_and_execute:
      Url (http) of a file to be fetched and executed at the end of the installation (default = '')
    • release:
      Ubuntu release to be installed (default="trusty")
    • install_opsi-client-agent:
      The Linux opsi-client-agent is to be installed if true (this is a co-funding project and requires activation by /etc/opsi/modules) (default=false)

12.5.4. Netboot product for backup and restore

  • opsi-local-image-backup
    This product saves the OS which is installed on partition 1 as an image on partition 3. The image name will be set according to the property imageFile. If this is empty, the name of the opsi netboot product will be used, that currently is set to installed (e.g. opsi-local-image-winxp). This name also is set as the product property imagefile of the product opsi-local-image-restore, so that a following call of opsi-local-image-restore is going to restore this image. This name also will be added to the product property imagefiles_list of the product opsi-local-image-restore. So this property holds the list of all available images. Furthermore (for Windows products) the current opsi product settings will be saved together with the image, so they also can be restored.
    The backup tool in use is partclone.
    Properties:

    • imagefile
      name of the image file to be generated (default = empty = automated name setting). The name may include spaces, but no umlauts (like ä, ö, ü). (In case of spaces they will internally be treated as underscore. So my image = my_image.
  • opsi-local-image-restore
    This product restores the image defined by the product property imagefile to partition 1 and makes it bootable. Furthermore (for Windows products) the product settings connected with this image will be restored.
    Properties:

    • imagefile
      Name of the image to be restored. The value of this property has been set automatically by the last backup. The list of available images is to be found in the property imagefiles_list.
    • imagefiles_list
      List of all available images. This list is managed automatically by the backup product.
    • method
      method to be used to restore images. Available methods are partclone-image-restore and rsync-partclone-image. The default is set to rsync-partclone-image. The method rsync-partclone-image requires that the operating system that had been backuped is residing on partition 1. So this method can be used for restoring minor changes of the currently installed operating system, but it cannot switch between several operating systems. The method partclone-image-restore generates a full image backup. The method rsync-partclone-image currently (10.7.2013) is available for Windows (NTFS file system). If the method is set to rsync-partclone-image for a Linux image or for an image that has been generated from another Windows version as the one which is currently installed on the productive partition, it will automatically use the method partclone-image-restore.
      If the restore with the method rsync-partclone-image fails, the restore will continue automatically by using the method partclone-image-restore.
      The method rsync-partclone-image is advantageous in case of minor changes on slow (IDE) discs. With state of the art (SATA) discs we generally recommend using partclone-image-restore.
    • update_and_backup
      (true/false) default = false. If set to true, after the restore all localboot products, that have a different version on the server, will be set to setup and the product opsi-local-image-backup-starter will be set to once. This results in installing all available updates of the products and then automatically generating a backup.
    • setup_after_restore
      can be set to one or multiple opsi products, that after the restore are to be set to setup, so that after the reboot they will execute automatically. The default is set to the product windomain to add the restored client to the Windows domain again.
  • opsi-local-image-delete
    This product deletes the image given by the product property imagefile from the backup partition

    • imagefile
      Name of the image to be deleted (default = empty, results in an error when executing)

12.5.5. Localboot product for process control

  • opsi-local-image-backup-starter
    This localboot product sets the Netboot product opsi-local-image-backup to setup and reboots the client. This product has a very low priority of -98. This means, that all usual localboot products will be installed first. This feature can be used as follows:
    For a client the following products are set to setup:
  • The product opsi-local-image-restore
  • all localboot products that are outdated
  • The product opsi-local-image-backup-starter

This results in the following process order:

  1. restore of the image
  2. update of the restored operating system (all outdated products are updated)
  3. backup of the updated operating system

12.6. Extended opsi service methods

With this extension the clients of a training classroom can be listed as a opsi-client group. The following extensions have been implemented to provide comfortable collective action management for all clients of a classroom:

  • setProductActionRequestForHostGroup
    Parameter: hostGroupId, productId, actionRequest
    allows to start a defined action (like image restore) for all members of a group (e.g. clients of a training classroom).
  • setProductPropertyForHostGroup
    Parameter: productId propertyId propertyValue hostGroupId
    allows to set a given product property (like which image is to be restored) for all members of a group (e.g. clients of a training classroom).
  • getPossibleImagefileValuesForHostGroup
    Parameter: groupId
    gets the list of present imagefile names that have been generated by opsi-local-image-backup on all members of the group. If a special image (like opsi-local-image-winxp) is not available on one or more of the clients, it will not be on the returned list.

These methods will be integrated into the opsi standard packets at a later date. Until then these extensions are available by executing the file 40_groupActions.conf, which is part of this release. Please copy it with root rights to /etc/opsi/backendManager/extend.d and execute: opsi-setup --set-rights /etc/opsi.

12.7. Process steps

12.7.1. Initial Installation

The product opsi-local-image-prepare first generates the required static partitioning.

Figure 12.1. schema: static partitioning with opsi-local-image-prepare

schema: static partitioning with opsi-local-image-prepare

Then the products opsi-local-image-winxp, opsi-local-image-win7, opsi-local-image-win7-x64 and opsi-local-image-ubuntu can install several operating systems with different client configuration and different application software.

Figure 12.2. schema: OS installation with opsi-local-image-win*

schema: OS installation with opsi-local-image-win*

Per default after the installation they will be backuped as image.

Figure 12.3. schema: image backup with opsi-local-image-backup

schema: image backup with opsi-local-image-backup

12.7.2. Restoring an image

Executing the product opsi-local-image-restore per default restores the image that has been generated recently. In case a different image is to be restored, the name of the image has to be specified by the property imagefile.

Figure 12.4. schema: image restore with opsi-local-image-restore

schema: image restore with opsi-local-image-restore

12.7.3. Updating an image

By executing the product opsi-local-image-restore with the property setting update_and_backup = true the given image will be restored, all application software will be updated (as updates are available on the server) and finally a backup is generated.

12.7.4. Deleting an image

By executing the product opsi-local-image-delete the image that is specified by the property imagefile will be deleted.

12.8. Backup partition

The backup partion is (with MBR BIOS without data partition) the third partition of disc one.
It contains:

  • The file master.log with information about all image operations performed. This logfile is transfered to the bootimage logs.
  • The image files
    The image directories have the same name as the image and hold the image and the meta files of the image.
    To give an idea about file sizes, here as an example the sizes of different image files with OS and standard software (Libreoffice, Adobereader, firefox, thunderbird, javavm, flashplayer):
  • opsi-local-image-ubuntu: 3.6G
  • opsi-local-image-winxp: 6.4G
  • opsi-local-image-win7: 9.4G
  • opsi-local-image-win7-x64: 13G

12.9. Capture Images (WIM) generating and distribution

12.9.1. Capture Images (WIM) Introduction

Starting with NT6 (Vista) Microsoft has introduced the new image format Windows Imaging Format (WIM) for installation. A WIM image is not a disc or partition image anymore, but a file and meta archive. A WIM file can hold several images. The standard installation of a NT6 client is based on a setup.exe extracting an installation image from the file install.wim which is then to be configured and equipped with additional drivers.

From an existing client the Windows operating system including the installed software and configuration can be extracted and saved in form of a WIM. Then such a WIM can be the starting point for a new installation.

12.9.2. Capture Images (WIM) Components

The packet opsi-local-image consists of several components:

The netboot products:

  • opsi-local-image-capture

The localboot products:

  • opsi-local-image-backup-sysprep
  • opsi-set-wim-imagenames
  • opsi-del-wim-images
  • opsi-client-agent >= Version 4.0.4.5-3

12.9.3. Capture Images (WIM) Processing

Generating the master client:
this will be generated with opsi-local-image as client and can get software and configuration per opsi as well as manually.

sysprep: depersonalisation of the master:
for that an image can be the starting point of an installation, at first it must be prepared. The client has to be depersonalised, so that the client has no identity anymore and so can be the template for new installations. But being depersonalised it can not be used as a working client anymore.
So with the product opsi-local-image-sysprep by special properties can be configured, whether there has to be created a backup before depersonalisation:

always_backup_before_sysprep (true/false) default=true: always make a backup before starting the sysprep.

abort_on_no_backup (true/false) default=true: check whether the backup partition has a backup for this product and abort if not. After the sysprep usually the actual capture will be started, which is performed by the netboot product opsi-local-image-capture. Whether it starts automatically is set by the property:

startcapture (true/false) default=true: set the product

opsi-local-image-capture to setup and reboot the client.

Figure 12.5. capture images: configed: opsi-local-image-sysprep

capture images: configed: opsi-local-image-sysprep

capture: read the existing installation and provide for installation:
within this multi-stage process the existing client will be readout and integrated as WIM into an existing opsi Windows installation product. So there is a product property to define, in which product the image readout is to be integrated:

target_product: name of target product (default = '')

Important

this property isn’t smart, so it does not check whether the image matches the specified target. So you could by mistake integrate a Win7-32Bit into a Win81-64Bit product without getting an error or warning message. So you must take care not to do so! We recommend using special capture target products (like opsi-local-image-win81-x64-capture).

The target product, like the standard product for Windows installation must be prepared. The target file within the target product is install.wim (installfiles/sources/install.wim), that also includes the images provided by Microsoft. Whether the image readout has to be appended to this file or a new install.wim has to be generated, is defined by the property:

capture_mode (append/always_create) default = append:
with append the new image will be appended to the existing install.wim.

Important

In case the install.wim contains an image with the same name it will be deleted without notice. With always_create a new install.wim will be created.

The install.wim file is a container that can hold several images. The images have a name and a description. The name and the description of the new created images is set by these properties:

imagename default = ''

image_description default = ''

The property start_after_capture is a list of products, which have to be set to setup after the capture. This could be for instance opsi-local-image-restore, which restores the client from the backup that had been generated before the sysprep.

Figure 12.6. capture images: configed: opsi-local-image-capture

capture images: configed: opsi-local-image-capture

Figure 12.7. capture images: schema: sysprep

capture images: schema: sysprep

Figure 12.8. capture images: opsi-local-image-sysprep 1 : start

capture images: opsi-local-image-sysprep 1 : start

Figure 12.9. capture images: opsi-local-image-sysprep 2 : backup before sysprep

capture images: opsi-local-image-sysprep 2 : backup before sysprepp

Figure 12.10. capture images: opsi-local-image-sysprep 3 : deactivating the opsi-client-agent

capture images: opsi-local-image-sysprep 3 : deactivating the opsi-client-agent

Figure 12.11. capture images: opsi-local-image-sysprep 4 : actual sysprep

capture images: opsi-local-image-sysprep 4 : actual sysprep

With the property startcapture the capture process can be started directly following the sysprep.
The capture process basically consists of two phases:
the actual capture process is performed by winpe on the disc. Therefore this must be prepared and this is phase one:

  • Aktivating WinPE as bootable partition, generating the required boot records and, if necessary, deactivating the drive letter for other partitions.
  • Reading the opsi meta data about installed products on the client and saving these date on the client in a temporary directory.
  • Some cleanups on the readout system.
  • Writing a command file, that initiates the capture process at the next start of WinPE.
  • Providing some more files for the processing of WinPE like the list of products from the property start_after_capture
  • Rebooting the client

Figure 12.12. capture images: schema: capture 1

capture images: sSchema: capture 1

During the second phase WinPE starts and executes the actual capture process. In detail:

  • mount the opsi_depot_rw share for writing.
  • check the architecture of WinPE (32/64 bit) and start the opsi-script in the corresponding architecture.
  • connect to the opsi-webservice
  • reactivating the drive letters
  • in case of append mode: check whether an image with this name exists and in case deletge this existing image.
  • start the capture process. Doing so, depending on the Windows version of the WinPE, on Windows 7 the program imagex from the opsi-local-image-capture product will be used. On Windows 8 the programm dism from WinPE will be used (with fallback to imagex).
  • The resulting logfiles will be merged.
  • check the list of images in the modified install.wim and set this list as the product property Imagenames of the target product, so that the new created image can be selected for installation.
  • set the product start_after_capture to setup.
  • deactivate the WinPE partition and activate the system partition (Windows). Including activating UEFI netboot if possible.
  • write the logfile to the server. It will be attached to the logfile from the opsi-local-capture bootimage process.
  • reboot

Figure 12.13. capture images: schema: capture 2

capture images: schema: capture 2

Figure 12.14. capture images: capture: delete an existing image

capture images: capture: delete an existing image

Figure 12.15. capture images: capture: capture and append the new image

capture images: capture: capture and append the new image

To rollout the generated image use the target product defined as target_product. Set the imagename to the name of the generated image and then the product can be installed like any other Windows installation. So all the standards like driver integration and installation of the opsi-client-agent are performed like with using the original Microsoft image.
One important aspect has to be taken into account: if on the client the image has been generated from, software had been installed per opsi, these installation files are restored when installing the opsi-client-agent. This results in the side effect, that, differing from the standard installation, not all the products that have been set to installed before the installation are set to setup. Because this standard feature would result in installing again all the products that have been integrated into the image. So in this case only those products will be installed, that have explicitely been set to setup before the OS installation.

Chapter 13. opsi Setup Detector

13.1. Introduction

The basic steps of software packaging and distribution are:

  • analyzing the setup and creating the files on the opsi workbench
  • packing the opsi package
  • installing the opsi package on the opsi server
  • installing the software on the clients (roll out)

The opsi setup detector is a tool for supporting the packaging of software to prepare for software rollouts. All the steps can be done from the graphical user interface: selecting and analyzing the setup, creating the files on the opsi workbench, packing and installing the package on the opsi server. For packing and installing, the opsi setup detector invokes the community projekt opsi Package Builder. When opening a setup file, the opsi setup detector checks whether it is a well known Installer type and then automatically detects the available parameters from the setup file. Over the time, by feed back from opsi users and increasing experience with different installer types and setup files, the setup detector will improve its ability to detect different setup types.

13.2. Preconditions for using the opsi Setup Detector

The opsi Setup Detector runs on Windows XP or above and is available on our download server as an installable opsi package: http://download.uib.de/opsi4.0/experimental/opsi-setup-detector

If also packets shall be packed and installed on the opsi server, the community projekt opsi Package Builder is required to be installed on the same Windows client. For further information about the opsi Package Builder see the Community Projects section of the opsi Forum: https://forum.opsi.org/viewforum.php?f=22

For creating the files and packets a writable Samba share to the opsi Workbench is required. Further on some software setups (especially for 64 bit software) require for analyzing and integration the matching Windows system. This means, that analyzing and integrating software for 64bit Windows7 might not run on a 32bit Windows XP Client. This must be considered in each individual case.

So this is the list of preconditions:

  • Windows clients from Windows XP and above
  • opsi package Builder installed and configured
  • writable Samba share to the opsi Workbench
  • opsi Setup Detector itself with all its helper files

13.3. Setting up the opsi Setup Detector

The opsi Setup Detector is a Windows program developed with Lazarus. It requires some additional helper files to analyze special Setup types and some templates to generate the files for a new opsi packet from. The opsi Setup Detector is available as an opsi package, which includes all its helper files (but not the community project opsi Packet Builder). After installing the opsi Setup Detector, just the Share to the opsi Workbench has to be configured as Packet BaseDir and then a setup file to analyze can be opened with File - Open Setup File And Analyze.

13.3.1. Language Support

When starting the opsi Setup Detector, the language of the Windows system is detected and, if for language xx a suitable language file languages\opsisetupdetector.xx.po is detected, it will be used. The opsi Setup Detector comes with German and English language files. Additional languages can be supported by generating a suitable language file.

13.3.2. Files of the opsi Setup Detector

The opsi Setup Detector package contains the following files:

  • opsisetupdetector.exe - the opsi Setup Detector itself
  • extractMSI.cmd - helper file for analyzing Setups with embedded MSI files
  • MSIInfo.js - helper file to analyze MSI files
  • innounp.exe - helper file to analyze Inno Setup files
  • innounp.htm - help for the innounp.htm helper file
  • favicon.ico - opsi Icon
  • languages\ - directory for language specific files
  • languages\opsisetupdetector.po - default language file (English)
  • languages\opsisetupdetector.de.po - German language file
  • languages\Help.en.html - English help file
  • languages\Help.de.html - German help file

To create new opsi packages on the opsi workbench, several template files are required. These templates will be copied and patched according to the information from the opsi Setup Detector:

  • files2opsi\OPSI\ - templates for the opsi packaging
  • files2opsi\OPSI\control
  • files2opsi\OPSI\postinst
  • files2opsi\OPSI\preinst
  • files2opsi\CLIENT_DATA\ - templates for the opsiscripts
  • files2opsi\CLIENT_DATA\setup.opsiscript
  • files2opsi\CLIENT_DATA\uninstall.opsiscript
  • files2opsi\CLIENT_DATA\delsub.opsiscript
  • files2opsi\CLIENT_DATA\check_advanced_exitcode.opsiscript
  • files2opsi\CLIENT_DATA\check_inno_exitcode.opsiscript
  • files2opsi\CLIENT_DATA\check_installshield_exitcode.opsiscript
  • files2opsi\CLIENT_DATA\check_installshieldmsi_exitcode.opsiscript
  • files2opsi\CLIENT_DATA\check_inno_exitcode.opsiscript
  • files2opsi\CLIENT_DATA\check_msi_exitcode.opsiscript

13.4. The Menu of opsi Setup Detektor

The menu on the upper left contains the following options:

  • File - (opens a sub menu, see below)
  • Help - show help in an opsi Setup detector window. The help file %ProgramFilesDir%\opsiSetupDetector\languages\Help.de.html also can be displayed with a browser.
  • About - Show program version

The menu option File opens a sub menu with:

  • Open Setup File and Analyze - select the Setup to be analyzed. This option has the same effect as the Open Setup File button on the Analyze Tab down at the right side and opens a file selection dialog, which shows all file types. The file selection dialog on the other setup tabs only shows files with the extension .MSI(MSI Tab) or .EXE (on all the other Tabs).
  • Create Logfile - The current content of the Analyze Tab will be written as logfile. The name of the created logfile is %TEMP%\opsitmp\opsiSetupDetector.log and will be shown when generating a logfile. The logfile will be generated when executing this command and only contains information, that is currently shown in the Analyze tab.
  • Exit - quits the opsi Setup Detektor

13.5. Automated Analysis of a Setup file

When opening a setup file with Open Setup File and Analyze, it will be analyzed automatically and, if it is a well known Installer type, automatically switched to the suitable tab. If the installer type is not detected, the Analyze tab keeps the focus. Even when the installer type was detected, you can switch back to the Analyze tab any time to check the info details sampled by the analysis.

When analyzing a MSI file, the extension .MSI already indicates a MSI setup file. When analyzing an .EXE file the extension is not very specific and could be anything. So the EXE file is scanned for special markers to indicate the installer type. If the marker of a well known Installer type is found, the focus switches to the corresponding installer type tab. This might give some clue to what kind of installer it is. If the Setup type cannot be detected, the file will be scanned for a special set of words like (e.g. "Installer" or "Setup") and the corresponding lines will be written to the Analyze tab. This also might show some cryptic text passages and error codes, which are contained within the setup file like:

o@dejDs@s@t@t@du@u@<v@w@w@lx@Hy@x@x{@X|@|@@@@L@x@@Inno Setup Setup Data
The Setup has detected a serious error and quits

This just means, that these strings are found within the setup file and match the search pattern, so they are written to the Analyze Tab . In this case the search pattern is "Setup". In case of an unknown setup type this might give some clue about the installer type. All output on the Analyze Tab, which is preceded by:

Analyzing: F:\<setup.exe>

und closed by:

default grep finished.

derives from the automated analysis. If the setup type is detected, it is written below "default grep finished". In case of a well known installer type, the focus switches to the corresponding Tab.

According to the installer type some more information is to be found in the Analyze tab. This will be discussed in each of the installer chapters.

The content of the Analyze tab is cleared when starting a new analysis and so only contains information from the current setup analysis.

13.6. Setup-EXE with embedded MSI

Before going into the different installer types, just a few general things about setup files with embedded MSI: at the moment the opsi Setup Detector automatically detects embedded MSI that are wrapped by by Advanced Installer and Installshield based EXE files. The opsi Setup Detector extracts and analyses the MSI and writes the detected information to the Advanced+MSI Tab or InstallShield+MSI Tab and additionally to the MSI Tab. An EXE file with embedded MSI can contain several different MSI packages, e.g. for different Windows platforms 32bit/64bit. Usually a setup like this detects the system to use the matching MSI. In this case, when analyzing a setup, only the MSI will be detected for the system where the opsi Setup Detector is running on. Such EXE files often have command line options to get more information about the package and install options. Also there might be several MST-files, which will be used in case of detectable conditions. To make a long story short: you never really know, what a setup might do under different conditions. So in most cases you just need the MSI code to patch the deinstallation script. So you just have to make sure, that you have captured all of the codes to be handled in the deinstallation script. For instance a MSI for 32bit and 64bit usually has got a different code. To get all of the codes, you can run the opsi Setup Detector on different platforms to grab the MSI codes. When the opsi Setup Detector detects an embedded MSI, it will be analyzed and the information is shown in the MSI tab. It is possible to create the opsi packet based on the MSI tab. But usually you would take the EXE file for the packet, for it is easier to adapt it to updates and also the EXE file might do some additional jobs.

During the analysis the MSI and other components of the EXE file will be extracted to the directory %TEMP%\opsitmp. Before doing so, the directory will be cleaned, so all files to be found there are from the current setup.

13.7. Supported Installer Types

Some of the well known installer types have pretty good standards and are accessible for automated analysis. From a MSI packet or an Inno Setup based Setup a lot of useful information can be detected automatically, whereas other Installer types, like NSIS, don’t make any information accessible. So in many cases the automatic analysis gives good results, but in other cases it doesn’t work at all or requires to work it over. With increasing experience from user results the detection skill of the opsi Setup Detector will surely improve.

MSI packages are the most important and widespread Installer type, so the MSI tab is the first one to follow the *Analyze tab, and then the others in alphabetical order.

13.7.1. Installer Type MSI

MSI files are the installer format of the Microsoft Windows Installer. Setups of type MSI can be detected by the file extension .MSI. The internal format of MSI packages is a well known standard, so the opsi Setup Detector can read several information from the packet to show on the Analyze tab and the MSI Tab, where the focus will switch to. When analysing a MSI, the detected information shown in the Analyze Tab looks like this:

Analyzing MSI: F:\Setups\MSI\7-zip\7-Zip.msi

Microsoft (R) Windows Script Host, Version 5.8
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

MSI file: F:\uib\setupdetector\Setups\MSI\7-zip\7-Zip.msi
Manufacturer: Igor Pavlov
ProductName: 7-Zip 4.57
ProductVersion: 4.57.00.0
ProductCode: {23170F69-40C1-2701-0457-000001000000}
UpgradeCode: {23170F69-40C1-2701-0000-000004000000}
MSI file size is: 0,9 MB
Estimated required space is: 5,2 MB

get_MSI_info finished

The detected information is extracted from the MSI packet and automatically fills in the MSI tab form. It is used to patch the opsiscript installation/deinstallation scripts:

  • MSI file: Name of the analysed MSI file
  • opsi Product ID: this is the name of the new opsi packet to be created. It is derived from the product name below, by substituting spaces and other invalid characters with -. The suggested opsi Product ID can be changed.
  • Product Name: this is the name of the software as detected from the MSI. This name can be changed, but most likely the detected name will fit.
  • Product Version: the version of the software as detected from the MSI. Usually the detected value can be taken, but it should contain only numbers and points.
  • MSI Product Code: the MSI product code as detected from the MSI. It will be used to patch the deinstall opsiscript. Caveat: a MSI product for 32bit and 64bit usually has a different product code.
  • Required Space: this value is not read from the MSI packet, but is assumed as being six times the size of the MSI file. Before installting the software on the client, the setup.opsiscript checks, whether there is enough disc space.
  • MSI File Size: the size of the MSI file.
  • use MST File: if there is a MST file (Transform file) to be found in the same directory (where the MSI file is), its name will be filled in this edit field and will be checked to use for installation. By using the Select button on the right, another MST file can be selected. By removing the selection mark on the left, the MST file will not be used.
  • Description: The product name is set to this edit space and can be supplemented with additional information to be shown in the product description of the opsi product.
  • License required: When this selection mark is checked, the opsiscript will be patched with license=true to indicate that a license is required.

In case of analysing an EXE file with embedded MSI, the MSI file will be extracted automatically and the detected information will be shown in the MSI tab in addition to the corresponding tab (Advanced+MSI or InstallShied+MSI).

13.7.2. Installer Type Advanced+MSI

The Advanced Installer is a tool for creating MSI packets that also can be embedded in EXE setup files. When the opsi Setup Detector detects an EXE file as an MSI embedded with Advanced Installer, it extracts the MSI file from the EXE file and analyses the information. The result is shown in the Advanced+MSI tab and in addition in the MSI tab. For further information on the MSI tab see chapter Section 13.7.1, “Installer Type MSI”.

When extracting and analysing an embedded MSI from an Advanced Installer setup the Analyze tab will look like this:

xxxxxxxxxxxxxxxxxxxxxxxxx
Analyzing AdvancedMSI Setup:
F:\Setups\AdvancedMSI\Phase5\phase562install.exe
Analyzing MSI from Setup
F:\Setups\AdvancedMSI\Phase5\phase562install.exe
cmd.exe /C "F:\Setups\AdvancedMSI\Phase5\phase562install.exe" /extract:e:\Temp\opsitmp\
!! PLEASE WAIT !!
!! PLEASE WAIT !! Extracting and analyzing MSI ...
!! PLEASE WAIT !!
e:\Temp\opsitmp\*.msi
Analyzing MSI: e:\Temp\opsitmp\phase5.msi

The MSI will be extracted to the directory =%TEMP%\opsitmp= and then analysed. With the result the Advanced+MSI tab will be filled in:

  • Setup file: Name of the analysed setup file
  • opsi Product ID: this is the name of the new opsi packet to be created. It is derived from the product name below, by substituting spaces and other invalid characters with -. The suggested opsi Product ID can be changed.
  • Product Name: this is the name of the software as detected from the MSI. This name can be changed, but most likely the detected name will fit.
  • Product Version: the version of the software as detected from the MSI. Usually the detected value can be taken, but it should contain only numbers and points.
  • MSI Product Code: the MSI product code as detected from the MSI. It will be used to patch the deinstall opsiscript. Caveat: a MSI product for 32bit and 64bit usually has a different product code and an Advanced Installer packet might contain different MSI files. In this case it depends on the system the analysis is running on, which MSI is extracted and analysed. Usually a 64bit MSI cannot be extracted on a 32bit system. So for packing a 64bit software, a 64 system should be used.
  • Required Space: this value is not read from the MSI packet, but is assumed as being six times the size of the EXE file. Before installting the software on the client, the setup.opsiscript checks, whether there is enough disc space.
  • Setup File Size: the size of the EXE file.
  • Description: The product name is set to this edit space and can be supplemented with additional information to be shown in the product description of the opsi product.
  • License required: When this selection mark is checked, the opsiscript will be patched with license=true to indicate that a license is required.

Signature Advanced+MSI: for detection of an Advanced+MSI setup, the EXE file is scanned for the marker:

name="microsoft.windows.advancedinstallersetup

13.7.3. Installer Type Inno Setup

Setups created with Inno Setup follow a pretty well known standard and contain a special file named install_script.iss, which can be extracted from the EXE file. The information from install_script.iss is filled into the edit fields of the Inno Setup tab and the focus switches to this tab. Going back to the Analyze Tab it looks like this:

............................................
Analyzing: F:\Setups\Inno\openssl\Win32OpenSSL_Light-1_0_0i.exe
stringsgrep started (verbose:false, skipzero:false)
found string "<description>Inno Setup</description>"
detected Inno Setup
stringsgrep completed (verbose:false, skipzero:false)
............................................
Analyzing Inno-Setup:
extract install_script.iss from F:\Setups\Inno\openssl\Win32OpenSSL_Light-1_0_0i.exe to
C:\ProgramData\opsi setup detector\INNO\Win32OpenSSL_Light-1_0_0i\install_script.iss
"E:\Program Files (x86)\opsiSetupDetector\innounp.exe" -x -a -y -d"C:\ProgramData\opsi setup detector\INNO\Win32OpenSSL_Light-1_0_0i" F:\Setups\Inno\openssl\Win32OpenSSL_Light-1_0_0i.exe install_script.iss
; Version detected: 5402
#66 install_script.iss
C:\ProgramData\opsi setup detector\INNO\Win32OpenSSL_Light-1_0_0i\install_script.iss
........
[Setup]
AppName=OpenSSL Light (32-bit)
AppVerName=OpenSSL 1.0.0i Light (32-bit)
AppPublisher=OpenSSL Win32 Installer Team
AppPublisherURL=http://www.openssl.org
AppSupportURL=http://www.slproweb.com
AppUpdatesURL=http://www.slproweb.com/products/Win32OpenSSL.html
DefaultDirName={sd}\OpenSSL-Win32
DefaultGroupName=OpenSSL
OutputBaseFilename=Win32OpenSSL_Light-1_0_0i
Compression=bzip2
........
Setup file size is: 1,9 MB
Estimated required space is: 11,1 MB
........
get_inno_info finished
Inno Setup detected

The information from install_script.iss is taken to fill in the edit fields of the Inno Setup tabs to patch the opsiscripts:

  • Setup file: Name of the analysed setup file
  • opsi Product ID: this is the name of the new opsi packet to be created. It is derived from the product name below, by substituting spaces and other invalid characters with -. The suggested opsi Product ID can be changed.
  • Product Name: this is the name of the software as detected from install_script.iss. This name can be changed, but most likely the detected name will fit.
  • Product Version: the version of the software as detected from install_script.iss. Usually the detected value can be taken, but it should contain only numbers and points.
  • Install Directory: this is the name of the directory, where the software is supposed to be installed on the client. This is taken to patch the deinstall script. The installation dir is read from install_script.iss and usually can be taken as is. But sometimes this entry might contain some Inno Setup specific notations, which are usually enclosed in curly braces. Some of them the opsi Setup Detector will translate to opsiscript syntax, like There could be a number of other entries in curly brackets, which opsiscript does not understand. In this case manual translation to opsiscript syntax is required. The entry UninstallDisplayName from install_script.iss might give some clue to this. A list and description of Inno Setup constants can be found in the Inno Setup help, e.g. http://www.jrsoftware.org/ishelp/index.php
  • Required Space: this value is not read from install_script.iss, but is assumed as being six times the size of the EXE file. Before installting the software on the client, the setup.opsiscript checks, whether there is enough disc space.
  • Setup File Size: the size of the EXE file.
  • Description: The product name is set to this edit space and can be supplemented with additional information to be shown in the product description of the opsi product.
  • License required: When this selection mark is checked, the opsiscript will be patched with license=true to indicate that a license is required.

Signature Inno Setup: for detecting a setup as Inno Setup, the EXE file is scanned for the marker:

<description>inno setup</description>

13.7.4. Installer Type InstallShield

EXE files created with Installshield are not accessible for automated analysis. It just can be detected, that it is a setup of type Installshield. So all the entries to be found in the InstallShield tab are derived from the name of the setup file. So if the filename is simply Setup.exe, the edit fields will be filled with Setup. In addition it depends on the Installshield version, what command line parameters are accepted by the setup and the deinstallation program. So integrating an Installshield setup is mainly manual work. The first test could be to check out available command line parameters of the setup, e.g. with setup -?. More and more Installshield packets contain embedded MSI files. So pure Installshield packets without MSI will become less important.

When analysing an Installshield setup, the Analyze tab looks like this:

.....................................
Analyzing: F:\uib\setupdetector\Setups\InstallShield\viclient\VMware-viclient.exe
stringsgrep started (verbose:false, skipzero:false)
found string "InstallShield"
detected InstallShield Setup
stringsgrep completed (verbose:false, skipzero:false)
.....................................
Analyzing InstallShield-Setup:
Setup file size is: 32,1 MB
Estimated required space is: 192,6 MB
........
get_InstallShield_info finished
InstallShield Setup detected

The edit fields of the InstallShield tab are:

  • Setup file: Name of the analysed setup file
  • opsi Product ID: this is the name of the new opsi packet to be created. It is derived from the product name below, by substituting spaces and other invalid characters with -. The suggested opsi Product ID can be changed.
  • Product Name: this is the name of the software as detected from the setup filename. Most likely it has to be adapted.
  • Product Version: the version of the software as detected from from the setup filename. It should contain only numbers and points and most likely has to be adapted .
  • Install Directory: this is the name of the directory, where the software is supposed to be installed on the client. This is taken to patch the deinstall script and must be set manually
  • Required Space: this value is assumed as being six times the size of the EXE file. Before installting the software on the client, the setup.opsiscript checks, whether there is enough disc space.
  • Setup File Size: the size of the EXE file.
  • Description: The product name is set to this edit space and can be supplemented with additional information to be shown in the product description of the opsi product.
  • License required: When this selection mark is checked, the opsiscript will be patched with license=true to indicate that a license is required.

Signature InstallShield: for detecting an Installshield setup file, the EXE is scanned for the marker:

<description>InstallShield.Setup</description>

Finding the Installshield signature without detecting the marker for embedded MSI, the setup is assumed to be of type InstallShield. If also the marker for an embedded MSI is found, the setup is assumed to be of type InstallShield+MSI (see below).

13.7.5. Installer Type InstallShield+MSI

Setups created with InstallShield often contain embedded MSI files. To extract the MSI file from the EXE file, a batch is invoked to start the setup and wait for a MSI file to be extracted. The batch will wait for about 10 seconds for a MSI file to appear and then kill the setup tasks. The extracted MSI will be analysed and the gathered information will be shown in the InstallShield+MSI tab and the MSI tab. It depends on the EXE file and the system conditions, whether it extracts an MSI file or not. Eventually it does not extract any MSI for the operating system is not suitable or because ther is a GUI question waiting to be answered. If the automated extraction fails, the MSI might be unpacked manually and analysed as MSI. These entries can be transfered to the InstallShield+MSI tab.

In case of a successful InstallShield+MSI analysis the Analyze tab looks like this:

.....................................
Analyzing: F:\Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe
stringsgrep started (verbose:false, skipzero:false)
found strings "Installer,MSI,Database" and "InstallShield"
detected InstallShield+MSI Setup (InstallShield with embedded MSI)
found strings "Installer,MSI,Database" and "InstallShield"
detected InstallShield+MSI Setup (InstallShield with embedded MSI)
stringsgrep completed (verbose:false, skipzero:false)
.....................................
Analyzing InstallShield+MSI Setup: F:\Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe
Analyzing MSI from InstallShield Setup F:\Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe
cmd.exe /C E:\Program Files (x86)\opsiSetupDetector\extractMSI.cmd "F:Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe"
!! PLEASE WAIT !!
!! PLEASE WAIT !! Extracting and analyzing MSI ...
!! PLEASE WAIT !!
e:\Temp\opsitmp\*.msi
Analyzing MSI: e:\Temp\opsitmp\phase5.msi
cmd.exe /C cscript.exe "E:\Program Files (x86)\opsiSetupDetector\msiinfo.js" "e:\Temp\opsitmp\phase5.msi"
........
Microsoft (R) Windows Script Host, Version 5.8
Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten.

MSI file: e:\Temp\opsitmp\phase5.msi
Manufacturer: Systemberatung Schommer
ProductName: Phase 5 HTML-Editor
ProductVersion: 5.6.2.3
ProductCode: {20B1B020-DEAE-48D1-9960-D4C3185D758B}
UpgradeCode: {C63B6E47-6A28-44B6-A2C9-2BF084491FAD}
MSI file size is: 0,3 MB
Estimated required space is: 1,7 MB
........
get_MSI_info finished
Setup file size is: 15,4 MB
Estimated required space is: 92,7 MB
........
get_InstallShield_info finished
InstallShield+MSI Setup detected

If the automated extraction of the MSI succeeds, the detected valueswill be written to the InstallShield+MSI tab:

  • Setup file: Name of the analysed setup file
  • opsi Product ID: this is the name of the new opsi packet to be created. It is derived from the product name below, by substituting spaces and other invalid characters with -. The suggested opsi Product ID can be changed.
  • Product Name: this is the name of the software as detected from the setup filename. Most likely it has to be adapted.
  • Product Name: this is the name of the software as detected from the MSI. This name can be changed, but most likely the detected name will fit.
  • Product Version: the version of the software as detected from the MSI. Usually the detected value can be taken, but it should contain only numbers and points.
  • MSI Product Code: the MSI product code as detected from the MSI. It will be used to patch the deinstall opsiscript. Caveat: a MSI product for 32bit and 64bit usually has a different product code and an Advanced Installer packet might contain different MSI files. In this case it depends on the system the analysis is running on, which MSI is extracted and analysed. Usually a 64bit MSI cannot be extracted on a 32bit system. So for packing a 64bit software, a 64 system should be used.
  • Required Space: this value is not read from the MSI packet, but is assumed as being six times the size of the EXE file. Before installting the software on the client, the setup.opsiscript checks, whether there is enough disc space.
  • Setup File Size: the size of the EXE file.
  • Description: The product name is set to this edit space and can be supplemented with additional information to be shown in the product description of the opsi product.
  • License required: When this selection mark is checked, the opsiscript will be patched with license=true to indicate that a license is required.

Signature InstallShield+MSI: for the automated detection of an Installshield setup with embedded MSI the EXE file is scanned for the Installshield marker and the marker for an embedded MSI:

<description>InstallShield.Setup</description>
...
installer,msi,database

If both of them are found, the EXE file is supposed to be InstallShield+MSI.

13.7.6. Installer Type NSIS

NSIS setups are known to be small and fast. But it is not possible to extract further information from the packet, besides from detecting it as a NSIS setup. All further information to be shown is derived from the name of the setup. So the information must be sampled manually (for instance by installing the setup).

The entries in the Analyze tab might look like this:

...................................
Analyzing: F:\Setups\NSIS\7z920\7z920.exe
stringsgrep started (verbose:false, skipzero:false)
found string "Nullsoft.NSIS.exehead"
detected NSIS Setup
stringsgrep completed (verbose:false, skipzero:false)
...................................
Analyzing NSIS-Setup:
Setup file size is: 1,1 MB
Estimated required space is: 6,4 MB
........
get_nsis_info finished
NSIS (Nullsoft Install System) detected

The edit fields of the NSIS tab are:

  • Setup file: Name of the analysed setup file
  • opsi Product ID: this is the name of the new opsi packet to be created. It is derived from the product name below, by substituting spaces and other invalid characters with -. The suggested opsi Product ID can be changed.
  • Product Name: this is the name of the software as detected from the setup filename. Most likely it has to be adapted.
  • Product Version: the version of the software as detected from from the setup filename. It should contain only numbers and points and most likely has to be adapted.
  • Install Directory: this is the name of the directory, where the software is supposed to be installed on the client. This is taken to patch the deinstall script and must be set manually.
  • Required Space: this value is assumed as being six times the size of the EXE file. Before installting the software on the client, the setup.opsiscript checks, whether there is enough disc space.
  • Setup File Size: the size of the EXE file.
  • Description: The product name is set to this edit space and can be supplemented with additional information to be shown in the product description of the opsi product.
  • License required: When this selection mark is checked, the opsiscript will be patched with license=true to indicate that a license is required.

Signatur NSIS: for detecting a NSIS Setup, the EXE file will be scanned for the marker:

Nullsoft.NSIS.exehead
...
Nullsoft Install System

13.8. Creating a new opsi Packet

After analyzing the setup and the edit fields of the corresponding tab being filled, clicking the button Create opsi Packet (on the lower right) generates the files for a new opsi product.

Attention:

  • the Packet BaseDir must be a writable share to the opsi Workbench.
  • for safety reasons a new opsi packet only can be created if it doesn’t exist. To rewrite the product, first delete the product directory from the opsi workbench.

Left of the Create opsi Packet button are three available options to specify the operation of the button:

  • create opsi packet: the product directory and the corresponding files will be generated and patched on the opsi workbench. The packet will not be packed nor installed.
  • create opsi packet and start interactive PacketBuilder: as above the files will be created and patched and then the opsi Packet Builder will be started. The product data will be passed to the Packet Builder and the packet can be packed and installed in interactive mode. After completion the opsi Packet Builder should be closed to be startable again for the next data transfer.
  • create and auto -build -install -quiet: as above the directory and the files will be generated and patched and for further actions the opsi Packet Builder will be started. The opsi product data will be passed to the packet Builder and the packet will be built and installed, if the corresponding options are checked. If e.g. the packet just should be packed but not installed, the checkmark at install can be removed. Additionally the checkmark quiet can be set to execute the opsi Packet Builders without showing its user interface. After completion the opsi Packet Builder should be closed again.

For installation, configuration and instructions for the Community Project opsi Packet Builder see https://forum.opsi.org/viewforum.php?f=22

Chapter 14. Miscellaneous

14.1. Changelogs:

14.1.1. Changelog opsi-configed

opsi-configed (4.0.5.1.2-1) testing; urgency=low

  • use remoteurl instead of depotserver url for install package as well

    -- rupert roeder <roeder@bonifax.uib.local>  Wed, 22 Aug 2014 09:38:22 +0200

opsi-configed (4.0.5.1.1-1) testing; urgency=low

  • use remoteurl instead of depotserver url

    -- rupert roeder <roeder@bonifax.uib.local>  Wed, 21 Aug 2014 09:38:22 +0200

opsi-configed (4.0.5.1-1) testing; urgency=low

  • redesign of some data structures

    -- rupert roeder <roeder@bonifax.uib.local>  Wed, 20 Aug 2014 09:38:22 +0200

opsi-configed (4.0.4.2.9-1) experimental; urgency=low

  • message window when heap overflow

    -- rupert roeder <roeder@bonifax.uib.local>  Wed, 13 Apr 2014 09:38:22 +0200

opsi-configed (4.0.4.2.7-1) experimental; urgency=low

  • less fat data transmission for swaudit

    -- rupert roeder <roeder@bonifax.uib.local>  Wed, 09 Apr 2014 09:38:22 +0200

opsi-configed (4.0.4.2.5-1) experimental; urgency=low

  • integrating accelerated swaudit into selection methods
  • data loading observer pattern for configed start

    -- rupert roeder <roeder@bonifax.uib.local>  Mon, 01 Apr 2014 14:10:37 +0100

opsi-configed (4.0.4.2.4-1) experimental; urgency=low

  • activity indicator
  • created stub class for remote data
  • several data types included in stub
  • accelerated swaudit function

    -- rupert roeder <roeder@bonifax.uib.local>  Fri, 14 Mar 2014 14:10:37 +0100

opsi-configed (4.0.4.2.3-1) experimental; urgency=low

  • accelerated depot switching
  • other depot issues fixed
  • gzip compression is no default

    -- rupert roeder <roeder@bonifax.uib.local>  Thu, 13 Mar 2014 14:10:37 +0100

14.1.2. Changelog opsi-client-agent

opsi-client-agent (4.0.5.1-8) stable; urgency=low

  • opsiclientd 4.0.80
  • setup.ins: switch to fatal on Linux (do)
  • update to opsi-winst 4.11.4.10 (do)

— Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 23 Sep 2014 03:09:00 +0100

opsi-client-agent (4.0.5.1-7) stable; urgency=low

  • opsiclientd 4.0.79

— Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 25 Jul 2014 03:09:00 +0100

opsi-client-agent (4.0.5.1-6) stable; urgency=low

  • opsiclientd 4.0.78

— Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 25 Jul 2014 03:09:00 +0100

opsi-client-agent (4.0.5.1-5) stable; urgency=low

  • fixes in sub_restore_productOnClient for opsi-local-image

— Detlef Oertel <d.oertel@uib.de> Fri, 25 Jul 2014 15:00:00 +0100

opsi-client-agent (4.0.5.1-4) stable; urgency=low

  • fixes broken gina chain if Winlogon.GinaDLL=thirdpartygina and opsi.org\opsi-client-agent] NextGina=msgina.dll setup.py fixes # 1100
  • for oli productOnClient restore: restore existing actionrequests=setup after json restore (do)
  • code cleanup (preloginloader) from uninstall (do)

— Bardo Wolf <b.wolf@uib.de> Fri, 27 Jun 2014 10:49:00 +0100

opsi-client-agent (4.0.5.1-3) stable; urgency=low

  • for oli productOnClient restore: in opsiServiceCall_get_productOnClient condition "actionRequest":"none" So we delete only the localboot products with no actionrequest
  • update to opsenssl 1.0.1h
  • opsi-winst 4.11.4.6
  • fix in setup.py fixes # 1100

— Detlef Oertel <d.oertel@uib.de> Wed, 18 Jun 2014 15:00:00 +0100

opsi-client-agent (4.0.5.1-2) stable; urgency=low

  • delete new opsiclientd.conf sections for combination wan/vpn with install by shutdown
  • for oli productOnClient restore: in opsiServiceCall_get_productOnClient condition "actionRequest":"none" So we delete only the localboot products with no actionrequest

    -- Karsten Koepke <k.koepke@uib.de>  Thu, 13 Jun 2014 15:00:00 +0100

opsi-client-agent (4.0.5.1-1) stable; urgency=low ; RELEASED

  • added new opsiclientd.conf sections for combination wan/vpn with install by shutdown
  • fix in sub_restore_productOnClient (set bootmode to bkstd )

    -- Miriam Michaelis <m.michaelis@uib.de>  Tue, 10 Jun 2014 15:00:00 +0100

opsi-client-agent (4.0.5-1) stable; urgency=low

  • changed setup.ins (delete loginblocker logfile and timeout file)
  • fix in sub_restore_productOnClient (use $INST_ClientId$ instead of %HostId%)
  • new: in property uac_value new value 0=no change (experimental)

    -- Miriam Michaelis <m.michaelis@uib.de>  Tue, 29 Apr 2014 15:00:00 +0100

opsi-client-agent (4.0.4.5-4) stable; urgency=low

  • opsi-winst 4.11.4.4

    -- Detlef Oertel <d.oertel@uib.de>  Fri, 25 Apr 2014 15:00:00 +0100

opsi-client-agent (4.0.4.5-3) stable; urgency=low

  • new opsiloginblocker.dll V1.2.0.5/credential provider filter (no multiple timeouts)
  • new opsigina.dll 1.3.0.2 (no multiple timeouts)
  • fix in lib directory of opsi-winst; https://forum.opsi.org/viewtopic.php?f=6&t=6142
  • sub_restore_productOnClient: restore productOnClient if found in c:\opsi.org\tmp (for capture image use)
  • opsi-winst 4.11.3.11

    -- Miriam Michaelis <m.michaelis@uib.de>  Tue, 18 Mar 2014 15:00:00 +0100

opsi-client-agent (4.0.4.5-2) stable; urgency=low

  • opsi-winst 4.11.4.3
  • use of isDriveReady to disable critical-error-handler message box. (Drive not ready)

    -- Detlef Oertel <d.oertel@uib.de>  Thu, 20 Mar 2014 15:00:00 +0100

opsi-client-agent (4.0.4.5-1) stable; urgency=low

  • new credential provider filter with fix for >= nt6.2 opsiloginblocker.dll V1.2.0.2
  • loginblocker logfile written to dir opsi.org\log

    -- Miriam Michaelis <m.michaelis@uib.de>  Tue, 18 Mar 2014 15:00:00 +0100

14.1.3. Changelog opsi-winst

opsi-winst/opsi-script (4.11.4.10) stable; urgency=low

  • osparser: doAktionen: tsIncludeInsert: debug outputs for index out of range bug
  • osparser: LoadValidLinesFromFile : fix add loaded sub lines to FLinesOriginList to fix index out of range at tsIncludeInsert
  • osparser: new bool function: LineContaining_ExistsIn(<string>, <file name>)

— Detlef Oertel <d.oertel@uib.de> Wed, 01 Oct 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.9) stable; urgency=low

  • osfunc: StartProcess_cp: remove wrong setProgress which may lead to division by zero
  • osbatchgui: new var SavedBatchWindowMode
  • osparser: on NormalizeWinst and IconizeWinst save BatchWindowMode to SavedBatchWindowMode and set BatchWindowMode to new value. on RestoreWinst set to BatchWindowMode and mode to SavedBatchWindowMode Fixes changing the window mode by every sub section call (do_actions)

— Detlef Oertel <d.oertel@uib.de> Wed, 20 Aug 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.8) stable; urgency=low

  • osparser: more loggin on LLDebug2 in fileActionsMain: used source and target
  • osparser: more loggin on LLDebug2 in fileActionsMain: additional trim() an target

— Detlef Oertel <d.oertel@uib.de> Thu, 07 Aug 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.7) stable; urgency=low

  • osfunc: StartProcess_cp: if timeout is given: use Progressbar to show time progess until Timeout
  • new unit cCPUusage
  • skin.ini; new section [Activitybar]
  • osparser : Line Looping through append trailing '' fixes # 1116
  • osparser: typo double instead of doubble fixes #1117
  • new switch: AutoActivityDisplay = (true/false) default=false; if true shows marquee while winbatch/dosbatch
  • osfuncwin: RunCommandAndCaptureOut: non blocking readfile with PeekNamedPipe (so Activitybar may run in Background)
  • new manifest: with assemblyIdentity (needed for maquee style in Activitybar

— Detlef Oertel <d.oertel@uib.de> Wed, 23 Jul 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.6) stable; urgency=low

  • osmain: typo (dependenproducts) fixes #1078
  • osparser: typo (Windowds) fixes #1078
  • osconf: changed version to 4.11.4.6
  • osparser: fix: RegDeleteKey (https://forum.opsi.org/viewtopic.php?p=27061#p27061) #1086
  • osparser: set Fatal if shellbatch/execwith could not be executed. fixes #1074
  • osparser/oslog: new log file .history which always appends just the timestamp, name and version of the installed product.
  • osparser: PatchTextFile: new command: searchAndReplace <search str> <replace str> (works global and not case sensitive)
  • The temporary file names have now a random component in order to prevent conflicts between different instances of opsi-script. fixes #774
  • subsub bug fix: help to find sub sections in external sub section files (calling section as additional parameter in doAktionen)
  • osparser: getsublist: trim parameters before strtoint
  • osparser: getsublist: adjustBounds: fix for negative second parameter.

— Detlef Oertel <d.oertel@uib.de> Thu, 27 May 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.5) stable; urgency=low

  • unquote fix:
  • osparser: unquote function details moved to osfunc: opsiunquotestr function (because synautil.unquotestr is buggy: "tes’t" gives "test"
  • osfunc: new function opsiunquotestr
  • osfunc: use of opsiunquotestr in fileexists, chmod
  • osparser: use of opsiunquotestr in fileactionsmain
  • osmain: use of opsiunquotestr in getparameter
  • osparser: doRegistryAllNtUserDats: additional check if we can patch via HKU

— Detlef Oertel <d.oertel@uib.de> Thu, 19 May 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.4) stable; urgency=low

  • osfunclin: RunCommandAndCaptureOut: Log exitcode on Loglevel LLInfo
  • osparser: linkActionsMain: fix for index out of bound (while (i ⇐ Sektion.count)) fixes: #958
  • osfunc: StartProcess_cp: log error if time out is reached (inc’s error counter) fixes #506
  • new commands in PatchTextFile (osparser:doTextpatchMain): setKeyValueSeparator char sets Separator for key value pairs (default is =) setValueByKey keystr valuestr search exitsing key and sets the given value. If the key not exists, the key/value pair will be created below the line cursor.
  • osparser: scriptstopped := true on ExitWindows /ImmediateReboot and /ImmediateLogout
  • new function: getValueFromFile (<key string>,<file name> ) : string
  • new function: getValueFromFileBySeparator (<key string>,<separator string>,<file name> ) : string
  • new function: saveTextFile(<list>, < filename>) : bool
  • osparser: TuibInstScript.doAktionen: output initalized (created) fixes #974
  • osfunc: enhanced: TXStringList.getStringValue
  • osparser: produceStringlist: fix in emptylist() function

— Detlef Oertel <d.oertel@uib.de> Thu, 20 Mar 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.3) stable; urgency=low

  • opsparser: doFileActions: fix for mixed File section modifiers
  • osfunc: TuibRegistry.WriteEntry: fix logging if regtype is changed: fixes #780
  • osfunc: wait for parent ending also if waitforprocessending is true
  • osfunc: FileCopyWin: use of windows.copyFile instead of fileutils.copyFile
  • osparser: Stingreplace with IgnoreCase for %userprofiledir% fixes #877
  • osparser: new constant %opsiTmpDir% (c:\opsi.org\tmp ; /tmp )
  • osparser: new constant %opsiLogDir% (c:\opsi.org\log ; /var/log/opsi-client-agent/opsi-script )
  • osparser: new command: FatalOnRuntimeError (default = false)
  • osparser: takeString: LogError if index out of bounds; Fatal if FatalOnSyntaxError
  • oslog: escape control chars
  • osfunc: allcopy/execdelete: handle directories with additional attributes (e.g. hidden)
  • osparser: new function doRegistryNTUserDat
  • new Registry Parameter /NTuserDat: <path to ntuser.dat>
  • osmain: ProcessProduct: looks before processing a product if there is still a action request
  • osparser: for fileExists: replace GetFileInfo by "FileExists() or DirectoryExists()"
  • fixes to really stop the script interpretation after isfatalerror, issuccess, issuspended
  • new unit opsihwbiosinfo based on tsmbios
  • new infomap getHWBiosInfoMap
  • new bool function runningOnUefi fixes #908
  • new bool function isDriveReady(str)
  • doFileActions: disable windows critical Error Message boxes (SetErrorMode(SEM_FAILCRITICALERRORS))

— Detlef Oertel <d.oertel@uib.de> Mon, 9 Dec 2013:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.2) stable; urgency=low

  • make 4.11.4 working under windows
  • osencoding: searchencoding: new methode to read encoding
  • osinteractivegui: opendialog knows now *.ins and *.opsiscript
  • new string function reencodestr(str, from, to)
  • new stringlist function reencodestrlist(strlist, from, to)
  • new stringlist function shellCall( cmd ) ; returns the output of (sysnative) shell with cmd
  • getipByName now uses resolveip at linux
  • http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074%28v=vs.85%29.aspx
  • fix: use of sysnative with winbatch

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Sep 2013:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.1) stable; urgency=low

  • splitted project to opsi-script and opsi-script-nogui
  • splitted unit osmain to osmain and osinteractivegui
  • changed unit names: * wi* → os*
  • fixed: Feature 491 : real origin file and line number on syntax error (also on included parts)
  • new unit osencode which contain encoding functions known encodings are:
    UTF-8 utf8
    UTF-8BOM utf8bom
    Ansi ansi
    CP1250 cp1250
    CP1251 cp1251
    CP1252 cp1252
    CP1253 cp1253
    CP1254 cp1254
    CP1255 cp1255
    CP1256 cp1256
    CP1257 cp1257
    CP1258 cp1258
    CP437 cp437
    CP850 cp850
    CP852 cp852
    CP866 cp866
    CP874 cp874
    CP932 cp932
    CP936 cp936
    CP949 cp949
    CP950 cp950
    ISO-8859-1 iso8859-1
    ISO-8859-2 iso8859-2
    KOI-8 koi8
    UCS-2LE ucs2le
    UCS-2BE ucs2be
  • fixed: Bug 554 : includelogtail calls reencode
  • command IncludeLog has now an optional 3rd parameter sourceEncoding which may be auto, system or a valid encoding.
  • nearly all loadfromfile now with reencode
  • script encoding can now be given with for example encoding=utf8
  • loglevel of if/else/endif changed to LLinfo (6) fixes 539
  • loglevel of setLoglevel changed to LLinfo (6) fixes 535
  • new command IsSuspended interupts script execution and leave productOnClient unchanged Feature #614
  • shellbatch output is now captured
  • fix in linux getprocesslist: output now: short binary name;pid;user;full command line

— Detlef Oertel <d.oertel@uib.de> Tue, 30 Jul 2013:15:00:00 +0200

opsi-winst/opsi-script (4.11.4) stable; urgency=low

  • port to Linux
  • removed logginig via syslog
  • %opsiDepotId%
  • changed unit names:
  • wisynth → osparser
  • wibatch → osbatchgui
  • wimain → osmain
  • wifunc → osfunc
  • wiwin32 → osfuncwin2
  • new string function: getLinuxDistroType
  • new stringlist function: getLinuxVersionMap

— Detlef Oertel <d.oertel@uib.de> Tue, 30 Apr 2012:15:00:00 +0200

14.1.4. Changelog windows netboot products

windows (4.0.5-4) stable; urgency=low

  • update opsisetuplib.py
  • debug for winpe partition size bug
  • change partition (size/start/end) calculation to fix partition size bug (uib#2014101510000015)
  • property imagename now: editable: True

— Detlef Oertel <d.oertel@uib.de> Thu, 16 Oct 2014:15:00:00 +0200

windows (4.0.5-3) stable; urgency=low

  • update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200

windows (nt6) (4.0.5-2) stable; urgency=low

  • update opsisetuplib.py
  • hpsa support

— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200

windows (nt5) (4.0.5-2) stable; urgency=low

  • fix at $oem$ sub directories in opsi and custom directory

    -- detlef oertel <d.oertel@uib.de>  Mon, 04 Nov 2014 16:01:53 +0200

windows (4.0.5-1) stable; urgency=low

  • new property setup_after_install (do)
  • create_driver_links.py: do not extract buildIn-drivers from winpe
  • do not change UAC
  • update opsisetuplib.py
  • sort disks
  • reread changed from sfdisk to partprobe
  • small fix in sfdisk execution

    -- erol ueluekmen <e.ueluekmen@uib.de>  Fri, 18 Jul 2014 12:01:53 +0200

windows (4.0.4-3) stable; urgency=low

  • use of opsisetuplib.py
  • Swapoff all to avoid disk in use
  • copy of winpe_uefi removed

    -- detlef oertel <d.oertel@uib.de>  Fri, 11 Apr 2014 16:01:53 +0200

windows (4.0.4-2) stable; urgency=low

  • UEFI / GPT enabled

    -- detlef oertel <d.oertel@uib.de>  Tue, 25 Feb 2014 16:01:53 +0200

14.1.5. Changelog linux netboot products

Debian

debian-4.0.5-4 stable; urgency=low

  • update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200

debian-4.0.5-3 testing; urgency=low

  • update opsipreparelib.py
  • update opsisetuplib.py
  • hpsa support

— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200

debian-4.0.5-2 testing; urgency=low

  • localization fixes
  • locale-gen fixes
  • automatic release extension for (base-) opsi_online_repository
  • add opsi repository only if install_opsi_server
  • for squeeze 32 debiankernel = "linux-image-686"
  • more timezones

— Detlef Oertel <d.oertel@uib.de> Tue, 26 Aug 2014:15:00:00 +0200

debian-4.0.5-1 stable; urgency=low

  • added lvm
  • needs opsi 4.0.5 bootimage
  • new property use_logical_volumes
  • added HD-encryption
  • new property encrypt_logical_volumes (will set use_logical_volumes to True)
  • new property encrypt_password
  • need bootimage >= 20140704
  • more keymaps
  • property setup_after_install default now: "l-os-postinst"

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Jun 2014:15:00:00 +0200

debian-4.0.4-4 stable; urgency=low

  • use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
  • use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Fri, 20 May 2014:15:00:00 +0200

debian-4.0.4-3 stable; urgency=low

  • removed property use_raid1 (now always false)
  • removed property blockAlignment (now always true)

— Detlef Oertel <d.oertel@uib.de> Fri, 02 May 2014:15:00:00 +0200

debian_4.0.4-2 testing; urgency=low

  • retry on debootstrap
  • merged with ubuntu-4.0.4-2
  • use opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Mon, 17 Mar 2014:15:00:00 +0200

debian_7.02 testing; urgency=low

  • merged with ubuntu-4.0.4

— Detlef Oertel <d.oertel@uib.de> Tue, 10 Dec 2013:15:00:00 +0200

debian_6-5 testing; urgency=low

  • merged with ubuntu-12.0.4-5

— Detlef Oertel <d.oertel@uib.de> Mon, 22 Apr 2013:15:00:00 +0200

debian-4.0r3-1 testing; urgency=low

  • initial (J.Schneider ?) 13.5.2009

Ubuntu

ubuntu-4.0.5-7 testing; urgency=low

  • removed end-of-life releases (quantal,raring,saucy)
  • fix: create /etc/default/locale
  • fix: extend /etc/environment wit PATH

— Detlef Oertel <d.oertel@uib.de> Wed, 22 Oct 2014:15:00:00 +0200

ubuntu-4.0.5-6 testing; urgency=low

  • update opsisetuplib.py
  • code cleanup

— Detlef Oertel <d.oertel@uib.de> Mon, 22 Sep 2014:15:00:00 +0200

ubuntu-4.0.5-5 testing; urgency=low

  • update opsipreparelib.py
  • update opsisetuplib.py
  • hpsa support

— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200

ubuntu-4.0.5-4 testing; urgency=low

  • added release lucid
  • localization fixes
  • locale-gen fixes
  • automatic release extension for (base-) opsi_online_repository
  • add opsi repository only if install_opsi_server
  • more timezones

— Detlef Oertel <d.oertel@uib.de> Tue, 26 Aug 2014:15:00:00 +0200

ubuntu-4.0.5-3 stable; urgency=low

  • property setup_after_install default now: "l-os-postinst"

— Detlef Oertel <d.oertel@uib.de> Fri, 15 Aug 2014:15:00:00 +0200

ubuntu-4.0.5-2 stable; urgency=low

  • added HD-encryption
  • new property encrypt_logical_volumes (will set use_logical_volumes to True)
  • new property encrypt_password
  • need bootimage >= 20140704

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Jun 2014:15:00:00 +0200

ubuntu-4.0.5-1 stable; urgency=low

  • added lvm
  • needs opsi 4.0.5 bootimage
  • new property use_logical_volumes

— Detlef Oertel <d.oertel@uib.de> Wed, 4 Jun 2014:15:00:00 +0200

ubuntu-4.0.4-5 stable; urgency=low * added lvmClearVolumeGroups() * use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h) — Detlef Oertel <d.oertel@uib.de> Fri, 20 May 2014:15:00:00 +0200

ubuntu-4.0.4-4 stable; urgency=low

  • removed property use_raid1 (now always false)
  • removed property blockAlignment (now always true)

— Detlef Oertel <d.oertel@uib.de> Fri, 02 May 2014:15:00:00 +0200

ubuntu-4.0.4-3 testing; urgency=low

  • added trusty thar (14.04)
  • retries at debootstrap
  • use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 18 Mar 2014:15:00:00 +0200

ubuntu-4.0.4-2 UNRELEASED; urgency=low

  • needs now opsi linux bootimage version: 20140118
  • removed 64bit opsi-linux-bootimage and kernel from package
  • modified pxetemplate for new bootimage support
  • small fix in ubuntu.py
  • SERVER_DATA removed
  • fixed postinst
  • UEFI/GPT Support
  • new property setup_after_install

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri,  07 Feb 2014:01:00:00 +0200

ubuntu-4.0.4-1 experimental; urgency=low

  • needs now opsi linux bootimage version: 20131021
  • added 64bit opsi-linux-bootimage
  • new property: release
  • install linux-image after grup
  • additional run of update-grub
  • debootstrap script for saucy (copy from raring)
  • pkgdetails for all releases
  • removed property desktop

    -- Detlef Oertel <d.oertel@uib.de>  Tue,  24 Sep 2013:15:00:00 +0200

ubuntu-12.0.4-8 experimental; urgency=low

  • new property: proxy
  • dirtyhack in ubuntu.py: Devicefile not found by creating swap

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed,  21 Aug 2013:11:00:00 +0200

ubuntu-12.0.4-7 testing; urgency=low

  • new property: install_opsi-client-agent
  • integration of the Linux opsi-client-agent 4.0.3.2-1
  • some more ' --force-yes'

    -- Detlef Oertel <d.oertel@uib.de>  Mon,  1 Jul 2013:15:00:00 +0200

ubuntu-12.0.4-6 testing; urgency=low

  • timeout (1000 seconds) on debootstrap call

    -- Detlef Oertel / Erol Ueluekmen <info@uib.de>  Tue,  18 June 2013:15:00:00 +0200

ubuntu-12.0.4-5 testing; urgency=low

  • remove property: delete_partition_table (always/if_needed/never) (default=always)
  • new property: data_partition_preserve (always/if_possible/never) (default=never)
  • integrated 64bit opsi-linux-bootimage

    • version 20130427
    • kernel 3.6.11
    • python-opsi 4.0.3.2-1
  • added architecture productProperty
  • added 32 / 64 Bit Support (installs 64 Bit System if started from 64 Bit bootimage)
  • added UEFI/GPT Support
  • minimum disk size changed to 5GB

    -- Detlef Oertel / Erol Ueluekmen <info@uib.de>  Tue,  30 Apr 2013:15:00:00 +0200

ubuntu-12.0.4-4 testing; urgency=low

  • added desktop cinnamon. Will be installed on top of a unity
  • added property wget_and_execute
  • user now in sudo group
  • fixes in unity and xfce installation

    -- Detlef Oertel <d.oertel@uib.de>  Thu,  03 Apr 2013:15:00:00 +0200

ubuntu-12.0.4-3 testing; urgency=low

  • fit to partition scheme for opsi-image-local-(backup/restore)

    -- Detlef Oertel <d.oertel@uib.de>  Fri,  04 Jan 2013:15:00:00 +0200

ubuntu-12.0.4-2 testing; urgency=low

  • update ubuntu.py to opsi 4.0.2-3 standard

    -- Detlef Oertel <d.oertel@uib.de>  Mon,  17 Dec 2012:15:00:00 +0200

ubuntu-12.0.4-1 testing; urgency=low

  • update to 12.04

    -- Detlef Oertel <d.oertel@uib.de>  Fri,  14 Dec 2012:15:00:00 +0200

ubuntu-8.0.4-3 testing; urgency=low

  • changing source var to opsi_depot share (no more install)

    -- Detlef Oertel <d.oertel@uib.de>  Fri,  14 Dec 2012:15:00:00 +0200

ubuntu-8.0.4-2 testing; urgency=low

  • initial (J.Schneider ?) 13.5.2009

openSUSE

opensuse13-1_13.01-6 stable; urgency=low

  • fix repo URI ; fixes #1220
  • update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 21 Oct 2014:15:00:00 +0200

opensuse13-1_13.01-5 stable; urgency=low

  • update opsipreparelib.py
  • update opsisetuplib.py
  • hpsa support
  • code cleanup

— Detlef Oertel <d.oertel@uib.de> Fri, 26 Sep 2014:15:00:00 +0200

opensuse13-1_13.01-4 testing; urgency=low

  • use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)
  • code cleanup
  • new property: setup_after_install
  • new property: wget_and_execute

— Detlef Oertel <d.oertel@uib.de> Mon, 28 Jul 2014:15:00:00 +0200

opensuse13-1_13.01-3 testing; urgency=low

  • UUID for storage devices
  • added lvmClearVolumeGroups()
  • removed property use_raid1 (now always false)
  • removed property blockAlignment (now always true)
  • use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200

opensuse13-1_13.01-2 UNRELEASED; urgency=low

  • needs now opsi linux bootimage version: 20140118
  • removed 64bit opsi-linux-bootimage and kernel from package
  • modified pxetemplate for new bootimage support
  • SERVER_DATA removed
  • fixed postinst
  • fix install opsi server
  • UEFI/GPT Support
  • new property setup_after_install

— Detlef Oertel <d.oertel@uib.de> Tue, 18 Feb 2014:15:00:00 +0200

opensuse13-1_13.01-1 stable; urgency=low

  • port from opensuse12-3

— Detlef Oertel <d.oertel@uib.de> Tue, 9 Dec 2013:15:00:00 +0200

opensuse12-3_12.03-5 stable; urgency=low

  • fix repo URI ; fixes #1220
  • update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 21 Oct 2014:15:00:00 +0200

opensuse12-3_12.03-4 stable; urgency=low

  • update opsipreparelib.py
  • update opsisetuplib.py
  • hpsa support
  • code cleanup

— Detlef Oertel <d.oertel@uib.de> Fri, 26 Sep 2014:15:00:00 +0200

opensuse12-3_12.03-3 testing; urgency=low

  • UUID for storage devices
  • added lvmClearVolumeGroups()
  • removed property use_raid1 (now always false)
  • removed property blockAlignment (now always true)
  • use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
  • use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200

opensuse12-3_12.03-2 testing; urgency=low

  • needs now opsi linux bootimage version: 20140118
  • removed 64bit opsi-linux-bootimage and kernel from package
  • modified pxetemplate for new bootimage support
  • SERVER_DATA removed
  • fixed postinst
  • fix install opsi server
  • UEFI/GPT Support
  • new property setup_after_install

— Detlef Oertel <d.oertel@uib.de> Tue, 18 Feb 2014:15:00:00 +0200

opensuse12-3_12.03-1 stable; urgency=low

  • port from opensuse (version now part of name because rpms included)

— Detlef Oertel <d.oertel@uib.de> Tue, 9 Dec 2013:15:00:00 +0200

opensuse-12.03-2 experimental; urgency=low

  • minimal rpms

— Detlef Oertel <d.oertel@uib.de> Tue, 26 Sep 2013:15:00:00 +0200

opensuse-12.03-1 experimental; urgency=low

  • update to 12.03

— Detlef Oertel <d.oertel@uib.de> Tue, 24 Sep 2013:15:00:00 +0200

opensuse-10.03-1 experimental; urgency=low

  • initial (J.Schneider ?) 13.5.2009

sles11sp3

sles11sp3-11.3-10 stable; urgency=low

  • update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200

sles11sp3-11.3-9 stable ; urgency=low

  • fix in mount boot partition
  • hpsa support

— Detlef Oertel <d.oertel@uib.de> Tue, 09 Sep 2014:15:00:00 +0200

sles11sp3-11.3-8 stable ; urgency=low

  • use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
  • removed property use_raid1 (now always false)
  • removed property blockAlignment (now always true)
  • added lvmClearVolumeGroups()
  • suse_register with --no-refresh

— Detlef Oertel <d.oertel@uib.de> Wed, 20 Aug 2014:15:00:00 +0200

sles11sp3-11.3-7 stable ; urgency=low

  • needs now opsi linux bootimage version: 20140118
  • removed 64bit opsi-linux-bootimage and kernel from package
  • modified pxetemplate for new bootimage support
  • small fix in ubuntu.py
  • SERVER_DATA removed
  • fixed postinst
  • UEFI/GPT Support
  • new property setup_after_install
  • add install of kernel-firmware
  • rename grub.cfg to grub.conf

— Detlef Oertel <d.oertel@uib.de> Mon, 20 Jan 2014:15:00:00 +0200

sles11sp3-11.3-6 experimental; urgency=low

  • new product property: kernel_modules

— Detlef Oertel <d.oertel@uib.de> Wed, 15 Jan 2014:15:00:00 +0200

sles11sp3-11.3-5 experimental; urgency=low

  • create fstab and menu.lst with uuid instead of /dev/sda

— Detlef Oertel <d.oertel@uib.de> Thu, 09 Jan 2014:15:00:00 +0200

sles11sp3-11.3-4 experimental; urgency=low

  • some more logging
  • fix: local repositories
  • use different grub.cfg on unixDevicePath

— Detlef Oertel <d.oertel@uib.de> Wed, 18 Dec 2013:15:00:00 +0200

sles11sp3-11.3-3 experimental; urgency=low

  • fix: user softwareLicenseKey only if suse_register=true
  • update to bootimage 20131209

— Detlef Oertel <d.oertel@uib.de> Thu, 12 Dec 2013:15:00:00 +0200

sles11sp3-11.3-2 experimental; urgency=low

  • sles.py fixes: syntax error
  • added proxy handling
  • added productProperties suse_register and local_repositories

— Erol Ueluekmen <e.ueluekmen@uib.de> Tue, 29 Oct 2013:10:00:00 +0200

sles11sp3-11.3-1 experimental; urgency=low

  • port from opensuse package
  • property productkey for suse_register

— Detlef Oertel <d.oertel@uib.de> Tue, 28 Oct 2013:15:00:00 +0200

centos65

centos65_6.5-3 testing; urgency=low

  • added lvmClearVolumeGroups()
  • use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 05 Aug 2014:15:00:00 +0200

centos65_6.5-2 testing; urgency=low

  • retries at base installation
  • use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
  • new property setup_after_install
  • removed properies use_raid1 (always false) and block_alignment (always true)

— Detlef Oertel <d.oertel@uib.de> Mon, 28 Apr 2014:15:00:00 +0200

centos65_6.5-1 experimental; urgency=low

  • port from redhat65

— Detlef Oertel <d.oertel@uib.de> Mon, 3 Feb 2014:15:00:00 +0200

Fedora 20

fedora_20_20-4 stable; urgency=low

  • added lvmClearVolumeGroups()
  • removed property use_raid1 (now always false)
  • removed property blockAlignment (now always true)
  • use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)
  • new property setup_after_install
  • new property wget_and_execute
  • 32Bit support
  • removed property console_keymap - moved to l-os-postinst

— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200

fedora_20_20-3 stable; urgency=low

  • retries at base installation
  • use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 22 Apr 2014:15:00:00 +0200

fedora_20_20-1 stable; urgency=low

  • port from opensuse13-1

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Dec 2013:15:00:00 +0200

14.1.6. Changelog opsi-local-image

opsi-local-image-backup

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-backup (4.0.5.1-2) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-backup (4.0.5.1-1) stable; urgency=low

  • new property setup_after_install
  • disk sorting

    -- detlef oertel <d.oertel@uib.de>  Thu, 10 Jul 2014 16:01:53 +0200

opsi-local-image-backup (4.0.4.3-1) stable; urgency=low

  • opsisetuplib.py update
  • code cleanup

    -- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-backup (4.0.4.3-1) stable; urgency=low

  • use of opsisetuplib.py
  • remove action requests from poc store

    -- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-backup (4.0.4.2-1) stable; urgency=low

  • uefi / gpt support
  • Showing a progress bar when creating a backup.

    -- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-backup (4.0.4.1-1) stable; urgency=low

  • Handles imagefile names with spaces (internal as _)
  • fix: stores always the correct netboot product name

opsi-local-image-backup (4.0.3.2-1) stable; urgency=low

  • Now works also with 4 partitions

opsi-local-image-backup (4.0.3-4) stable; urgency=low

  • internal syntax fix: fix image list
  • use partclone with --dev-to-dev instead of --clone

opsi-local-image-backup (4.0.3-3) experimental; urgency=low

  • internal syntax fix: initialize goon

    • detlef oertel <d.oertel@uib.de> 11 Apr 2013

      opsi-local-image-backup (4.0.3-2) experimental; urgency=low
  • new product property imagefile

opsi-local-image-backup (4.0.3-1) experimental; urgency=low

opsi-local-image-capture

opsi-local-image-capture (4.0.5.1-5) stable; urgency=low

  • disabled all calls of ShellInAnIcon_copylog

    -- detlef oertel <d.oertel@uib.de>  Tue, 29 Jul 2014 16:01:53 +0200

opsi-local-image-win* (4.0.5.1-4) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-3) stable; urgency=low

  • delete c:\tmp before capture
  • delete c:\drv before capture

    -- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-2) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-1) stable; urgency=low

  • removed property capture_architecture
  • rewmoved property imagefilename
  • removed retry by sdfisk --re-read replaced by partprobe
  • code cleanup
  • fix gpt hidden winpe partition
  • windows partition before reboot and unhide while pe run (PE have to be c:)
  • auto detect drive letter for windows partition (may be different on existence of CD or other partitions)
  • fall back from dism to imagex if dism fails
  • uefi: switch back to uefi netboot (for e.g. opsi-local-image restore)

    -- detlef oertel <d.oertel@uib.de>  Tue, 15 Jul 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.4-2) stable; urgency=low

  • fixes in setup.py
  • special winst64.exe with ssl
  • removed use of property capture_architecture
  • rewmoved use of property imagefilename

    -- detlef oertel <d.oertel@uib.de>  Fri, 20 Jun 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.4-1) stable; urgency=low

  • switch back to PE based capture
  • modified winst32 with network connection

    -- detlef oertel <d.oertel@uib.de>  Thu, 5 Jun 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-1) stable; urgency=low

  • opsisetuplib.py update
  • needs opsi 4.0.5 bootimage
  • new property: netboot_product
  • new property: capture_architecture

    -- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.3-2) stable; urgency=low

  • use opsi_depot and opsi_depot_rw (samba4 executable bit problem) #* experimental: call winst32.exe #* new property: netboot_product
  • new property: capture_architecture

    -- detlef oertel <d.oertel@uib.de>  Mon, 28 Apr 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.3-1) stable; urgency=low

  • use of opsisetuplib.py
  • Swapoff all to avoid disk in use
  • remove action requests from poc store

    -- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.2-1) stable; urgency=low

  • initial: created from opsi-local-image-backup

    -- detlef oertel <d.oertel@uib.de>  Wed, 26 Mar 2014 16:01:53 +0200

opsi-local-image-delimage

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.5.1-2) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Thu, 24 Jul 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.5.1-1) stable; urgency=low

  • update of opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 22 Jul 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.4.3-1) stable; urgency=low

  • use of opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.4.2-1) stable; urgency=low

  • uefi / gpt support

    -- detlef oertel <d.oertel@uib.de>  Fri, 31 Jan 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.4.1-1) stable; urgency=low

  • Handles imagefile names with spaces (internal as _)

opsi-local-image-delimage (4.0.3.2-1) stable; urgency=low

  • Now works also with 4 partitions

opsi-local-image-delimage-4.0.3.1-2 testing; urgency=low

  • fix in type call

— Detlef Oertel <d.oertel@uib.de> Wed, 08 Apr 2013:15:00:00 +0200

opsi-local-image-delimage-4.0.3.1-1 testing; urgency=low

  • initial

— Detlef Oertel <d.oertel@uib.de> Wed, 13 Mar 2013:15:00:00 +0200

opsi-local-image-prepare

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.5.1-2) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.5.1-1) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 22 Jul 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-4) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 17 Jun 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-3) stable; urgency=low

  • start_os_installation editable: True

    -- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-2) stable; urgency=low

  • code cleanup
  • system_partition_size editable: True
  • data_partition_size editable: True

    -- detlef oertel <d.oertel@uib.de>  Tue, 27 May 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-1) stable; urgency=low

  • use of opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.2-3) stable; urgency=low

  • fix: Create backup partition: start is boundaryM + partgapM
  • library: createPartitionEx and createFilesystemEx with success test
  • smaller partGap : 64 M

    -- detlef oertel <d.oertel@uib.de>  Wed, 26 Mar 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.2-2) stable; urgency=low

  • swapoff all before partitioning
  • code cleanup

    -- detlef oertel <d.oertel@uib.de>  Thu, 27 Feb 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.2-1) stable; urgency=low

  • uefi / gpt support

    -- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-prepare (4.0.4.1-1) stable; urgency=low

  • rename to 4.0.4.1-1
  • added win81 products

    -- detlef oertel <d.oertel@uib.de>  Fri, 20 Dec 2013 16:01:53 +0200

opsi-local-image-prepare-4.0.3.2-1 testing; urgency=low

  • #267 Weitere Partitionsgrößen in "opsi-local-image-prepare"
  • new property: data_partition_size ; Default = 0G = partition will not be created
  • Now works also with 4 partitions

— Detlef Oertel <d.oertel@uib.de> Wed, 01 Aug 2013:15:00:00 +0200

opsi-local-image-prepare-4.0.3.1-1 testing; urgency=low

  • rename from opsi-local-image-repartition
  • added ProductProperty: start_OS_installation
  • added sleeps and 'sfdisk re-read’s and retrries to avoid timing problems after create partition

— Detlef Oertel <d.oertel@uib.de> Wed, 13 Feb 2013:15:00:00 +0200

opsi-local-image-repartition-4.0.3.1-1 testing; urgency=low

  • initial

— Detlef Oertel <d.oertel@uib.de> Wed, 13 Feb 2013:15:00:00 +0200

opsi-local-image-restore

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-restore (4.0.5.1-2) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-restore (4.0.5.1-1) stable; urgency=low

  • opsisetuplib.py update (new function setNextUefiBoot())
  • removed retry by sdfisk --re-read replaced by partprobe
  • fix: set next uefiboot via setNextUefiBoot()

    -- detlef oertel <d.oertel@uib.de>  Tue, 15 Jul 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.3-2) stable; urgency=low

  • opsisetuplib.py update
  • retry by sdfisk --re-read
  • fix: IndexError
  • try / except at restoring ntfs ACLs

    -- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.3-1) stable; urgency=low

  • use of opsisetuplib.py
  • do not use PE partition as swap (for reusing PE by capture)

    -- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.2-2) stable; urgency=low

  • raise exception if there is no meta data file

    -- detlef oertel <d.oertel@uib.de>  Mon, 25 Mar 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.2-1) stable; urgency=low

  • uefi / gpt support
  • Showing a progress bar when restoring a backup.

    -- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-restore (4.0.4.1-1) stable; urgency=low

  • Fix: failover from rsync to image if rsync fails
  • replace all not allowed image name chars with "_"

opsi-local-image-restore (4.0.3.2-2) stable; urgency=low

  • Fix: timeout increased from 100 to 1000

opsi-local-image-restore (4.0.3.2-1) stable; urgency=low

  • Now works also with 4 partitions

opsi-local-image-restore (4.0.3-7) stable; urgency=low

  • fix: method rsync-restore temporary activated again
  • partclone-image-restore uses now partclone.<fs> --dev-to-dev instaed of partclone.restore
  • mount for rsync uses mount.ntfs instead of imagemount
  • should be use d with backups from opsi-local-image-backup >= 4.0.3-4

opsi-local-image-restore (4.0.3-6) stable; urgency=low

  • fix: method rsync-restore temporary removed due to ntfs access rights problems and security risks

opsi-local-image-restore (4.0.3-5) experimental; urgency=low

  • fix: exclude symbolic links from rsync-restore use tar file instead should be use d with backups from 4.0.3-4

opsi-local-image-restore (4.0.3-4) stable; urgency=low

  • fix undefined myvalues in line 571

opsi-local-image-restore (4.0.3-3) stable; urgency=low

  • property method has now "rsync-partclone-image" as default
  • new property setup_after_restore

opsi-local-image-restore (4.0.3-2) experimental; urgency=low

  • fix: set partition type and bootflag

opsi-local-image-restore (4.0.3-1) experimental; urgency=low

opsi-local-image-sysprep

opsi-local-image-sysprep (4.0.5.1-1) stable; urgency=low

  • deactivate opsi-client-agent before sysprep
  • set uefi netboot before reboot if a netboot product is activated

    -- detlef oertel <d.oertel@uib.de>  Tue, 15 Jul 2014 16:01:53 +0200

opsi-local-image-sysprep (4.0.4.3-1) stable; urgency=low

  • more features

    -- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-sysprep (1.0-1) testing; urgency=low

  • Initial version based on opsi-sysprep

    -- d.oertel <d.oertel@uib.de> Wed, 26 Mar 2014 16:39:34 + 0100

opsi-local-image-win*

opsi-local-image-win* (4.0.5.1-6) stable; urgency=low

  • fix at $oem$ sub directories in opsi and custom directory

    -- detlef oertel <d.oertel@uib.de>  Mon, 04 Nov 2014 16:01:53 +0200

opsi-local-image-win* (4.0.5.1-5) stable; urgency=low

  • update opsisetuplib.py
  • update pci.ids, usb.ids

    -- detlef oertel <d.oertel@uib.de>  Mon, 29 Sep 2014 16:01:53 +0200

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.5.1-2) stable; urgency=low

  • update opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.5.1-1) stable; urgency=low

  • diskpart.txt is now gpt aware
  • no delete of opsi directory in PE via cleanup
  • create_driver_links.py: do not extract buildIn-drivers from winpe (eu)
  • code cleanup: no dual disk (ever only first disk)

    -- detlef oertel <d.oertel@uib.de>  Fri, 3 Jul 2014 10:01:53 +0200

opsi-local-image-win7 (4.0.4.3-3) stable; urgency=low

  • opsisetuplib.py update

    -- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.3-2) stable; urgency=low

  • fix in setup_after_install

    -- detlef oertel <d.oertel@uib.de>  Thu, 22 May 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.3-1) stable; urgency=low

  • use of opsisetuplib.py
  • property imagename now editable
  • Swapoff all to avoid disk in use
  • lvmClearVolumeGroups() to avoid disk in use

    -- detlef oertel <d.oertel@uib.de>  Fri, 28 Mar 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.2-2) stable; urgency=low

  • syntax fix

    -- detlef oertel <d.oertel@uib.de>  Thu, 27 Feb 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.2-1) stable; urgency=low

  • uefi / gpt support

    -- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-win7 (4.0.4.1-2) stable; urgency=low

  • UCS 3.2 Errata 4 fix: mount share from PE with valid domain: shareusername via webservice from clientconfig.depot.user

    -- detlef oertel <d.oertel@uib.de>  Thu, 16 Jan 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.1-1) stable; urgency=low

  • new product property setup_after_install: list of products which will be switched to setup with dependencies
  • if backup_after_install is true, the product property imageFile of opsi-local-image-backup will be set to '' (empty)

— detlef oertel <d.oertel@uib.de> 16 Dec 2013

opsi-local-image-win7 (4.0.3.2-1) stable; urgency=low

  • Now works also with 4 partitions

— detlef oertel <d.oertel@uib.de> 01 Aug 2013

opsi-local-image-win7 (4.0.3-2) stable; urgency=low

  • better error messages on wrong partition table

    -- uib GmbH <info@uib.de>  Wed, 17 Apr 2013 13:30:20 +0000

opsi-local-image-win7 (4.0.3-1) experimental; urgency=low

  • changed to match opsi-local-image standard

    -- uib GmbH <info@uib.de>  Wed, 13 Feb 2013 13:30:20 +0000

opsi-local-image-ubuntu

opsi-local-image-ubuntu (4.0.5.1-1) stable; urgency=low

  • ports from the 4.0.5 ubuntu product
  • trusty now default release
  • more keymaps
  • property setup_after_install default now: "l-os-postinst"

    -- detlef oertel <d.oertel@uib.de>  Mon, 11 Aug 2015 16:01:53 +0200

opsi-local-image-ubuntu (4.0.4.3-1) stable; urgency=low

  • use of opsisetuplib.py

    -- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-ubuntu (4.0.4.2-1) stable; urgency=low

  • uefi / gpt support

    -- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-ubuntu32 (4.0.4.1-1) stable; urgency=low

  • new product property setup_after_install: list of products which will be switched to setup with dependencies
  • if backup_after_install is true, the product property imageFile of opsi-local-image-backup will be set to '' (empty)

— detlef oertel <d.oertel@uib.de> 16 Dec 2013

opsi-local-image-ubuntu32 (4.0.3.2-2) stable; urgency=low

  • fix for 4 Partions (3rd part may be with label swap or winpe

— detlef oertel <d.oertel@uib.de> 24 Sep 2013

opsi-local-image-ubuntu32 (4.0.3.2-1) stable; urgency=low

  • Now works also with 4 partitions

— detlef oertel <d.oertel@uib.de> 01 Aug 2013

opsi-local-image-ubuntu32_4.0.3-3 stable; urgency=low

  • fixes in desktop installation of xfce and unity
  • desktop cinnamon added

— uib GmbH <info@uib.de> Mon, 1 Jul 2013 13:30:20 +0000

opsi-local-image-ubuntu32_4.0.3-2 stable; urgency=low

  • better error messages on wrong partition table

— uib GmbH <info@uib.de> Wed, 17 Apr 2013 13:30:20 +0000

opsi-local-image-ubuntu32_4.0.3-1 testing; urgency=low

  • changes to match opsi-local-image standard

— Detlef Oertel <d.oertel@uib.de> Fri, 01 Feb 2013:15:00:00 +0200

14.1.7. Changelog python-opsi

python-opsi (4.0.5.15-1) experimental; urgency=low

  • Patching sudoers: allow using service when no TTY present

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 14:30:24 +0200

python-opsi (4.0.5.14-1) experimental; urgency=low

  • 10_opsi.conf: New methods getHardwareAuditDataCount and getSoftwareAuditDataCount
  • DHCPD backend: Fix logging problem caused by string / unicode mixup.
  • OPSI.System.Posix.getServiceNames: Prefer "systemctl" over "service" to have a solution that flawlessly works on CentOS 7.
  • OPSI.System.Posix.locateDHCPDInit: Added search via getServiceNames

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 12:23:35 +0200

python-opsi (4.0.5.13-1) experimental; urgency=low

  • OPSI.System.Posix.Distribution: stripping the distribution attribute.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 14 Oct 2014 15:34:21 +0200

python-opsi (4.0.5.12-1) experimental; urgency=low

  • More work on OPSI.System.Posix.getSambaServiceName

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 14:50:17 +0200

python-opsi (4.0.5.11-2) experimental; urgency=low

  • Dropping python-simplejson as dependency because it is Pythons stdlib as json since Python 2.6

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 11:43:34 +0200

python-opsi (4.0.5.11-1) experimental; urgency=low

  • MySQL-backend: lower log-level for messages regarding transactions
  • Posix: added Methods getServiceNames and getSambaServiceName

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 06 Oct 2014 15:58:24 +0200

python-opsi (4.0.5.10-1) stable; urgency=low

  • DHCPD.py: small fix in restarting dhcp-service

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 16:54:50 +0200

python-opsi (4.0.5.9-1) stable; urgency=low

  • opsi-setup: changed restarting services over service calls instead of using init-scripts directly.

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 16:14:13 +0200

python-opsi (4.0.5.8-2) testing; urgency=low

  • python-crypto requirement modified for sles to python-pycrypto

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Mon, 29 Sep 2014 10:13:17 +0200

python-opsi (4.0.5.8-1) testing; urgency=low

  • FileBackend raises Exception if getRawData method is called.

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 23 Sep 2014 15:16:56 +0200

python-opsi (4.0.5.7-1) experimental; urgency=low

  • Preferring ldaptor over OPSI.ldaptor

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 10 Sep 2014 13:36:47 +0200

python-opsi (4.0.5.6-2) experimental; urgency=low

  • rpm-based packages: require python-pyasn1

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 16:55:20 +0200

python-opsi (4.0.5.6-1) experimental; urgency=low

  • Fix for certificate creation on SLES11SP3

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 25 Aug 2014 15:26:42 +0200

python-opsi (4.0.5.5-1) testing; urgency=medium

  • setProductActionRequestWithDependencies: added optional force parameter, to set dependend products even if they are installed

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Sat, 23 Aug 2014 02:37:20 +0200

python-opsi (4.0.5.4-3) testing; urgency=low

  • Also build on Ubuntu 10.04

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 22 Aug 2014 17:28:08 +0200

python-opsi (4.0.5.4-2) experimental; urgency=low

  • 40_groupActions.conf: _getClientsOnDepotByHostGroup get correct clients.
  • Debian: call dh --with python2

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 22 Aug 2014 17:18:16 +0200

python-opsi (4.0.5.3-2) experimental; urgency=low

  • SLES: Require libmagic1 for working python-magic

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 19 Aug 2014 12:55:00 +0200

python-opsi (4.0.5.3-1) experimental; urgency=low

  • Fix termination of KillableThread on newer Pythons

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 14:09:02 +0200

python-opsi (4.0.5.2-7) experimental; urgency=low

  • RHEL / CentOS: Depending on MySQL-python instead python-mysql
  • openSUSE / SLES: Fix depending on wrong version number for python-newt

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 06 Aug 2014 12:10:08 +0200

python-opsi (4.0.5.2-5) experimental; urgency=low

  • Dependencies for RHEL / CentOS 6 fixed and cleaned up .spec.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 06 Aug 2014 11:20:25 +0200

python-opsi (4.0.5.2-4) experimental; urgency=low

  • Re-Enabling dependency on python-ldaptor.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 16:39:12 +0200

python-opsi (4.0.5.2-2) experimental; urgency=low

  • Possible to build with python-support again.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 14:35:00 +0200

python-opsi (4.0.5.2-1) experimental; urgency=low

  • fix in write method for backendConfigFiles

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 03 Aug 2014 03:26:28 +0200

python-opsi (4.0.5.1-2) experimental; urgency=low

  • Using dh_python2

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 30 Jul 2014 17:38:00 +0200

python-opsi (4.0.5.1-1) experimental; urgency=low

  • New module: OPSI.Util.Task.Sudoers
  • 70_dynamic_depot.conf: Latency algorythm does even work if pinging a depot results in a timeout.
  • OpsiBackupArchive: Avoid hanging in an endless loop when running backupMySQLBackend and stderr gets spammed with the same message
  • DHCPD Backend: Trying to read the address of an client from the DHCPD configuration file if it can’t be resolved via DNS.
  • Certificate Creation: Using 2048 bit instead of 1024
  • small fix in getOpsiHostKey method
  • configed: direct access for mysql-backend users
  • forceUrl method don’t convert value to lower
  • OpsiBackupArchive: get path to mysqldump via which
  • Speeding up backend_getInterface, getArgAndCallString, objectToHtml, objectToBeautifiedText
  • New module: OPSI.Util.Task.ConfigureBackend.ConfigurationData
  • Added possibility to disable pigz in opsi.conf
  • SQL-Backends: Improved speed of query creation
  • Do not fail on removing installed products if the directory contains filenames with unicode characters
  • OPSI.System.Posix: Fixing reread partiontable problem with new bootimage
  • OPSI.System.Windows: Added setLocalSystemTime and getServiceTime in backend
  • Driverintegration: Fallback for byAudit to check if mainboard integration is possible.
  • OPSI.System.Posix: initializing bytesPerSector attribute in Harddisk class constructor
  • OPSI.Util.Repository: workarround timing problem after reconnect network adapter

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Thu, 28 Jul 2014 23:51:00 +0200

14.1.8. Changelog opsipxeconfd

opsipxeconfd (4.0.5.3-6) experimental; urgency=low

  • Removal on RHEL/CentOS should not fail anymore.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 16:21:06 +0200

opsipxeconfd (4.0.5.3-5) experimental; urgency=low

  • RPM: Fix problems with macro syntax.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 15:04:12 +0200

opsipxeconfd (4.0.5.3-4) experimental; urgency=low

  • RHEL/CentOS: Only removing the daemon in postun

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 14:21:31 +0200

opsipxeconfd (4.0.5.3-3) experimental; urgency=low

  • RHEL/CentOS: fixing problems on uninstall

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 12:30:07 +0200

opsipxeconfd (4.0.5.3-2) experimental; urgency=low

  • Fix for logrotate under SLES11SP3

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 25 Aug 2014 11:36:03 +0200

opsipxeconfd (4.0.5.3-1) experimental; urgency=low

  • Fix in modules handling

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Thu, 07 Aug 2014 01:45:00 +0200

opsipxeconfd (4.0.5.2-1) experimental; urgency=low

  • Fix in custom pxeConfTemplate-file handling.

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Mon, 04 Aug 2014 16:09:14 +0200

opsipxeconfd (4.0.5.1-3) experimental; urgency=low

  • Support for building with python-support added again.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 14:48:15 +0200

opsipxeconfd (4.0.5.1-2) experimental; urgency=low

  • Changed build system to dh_python2

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 30 Jul 2014 17:33:46 +0200

opsipxeconfd (4.0.5.1-1) experimental; urgency=low

  • Correctly stopping the service on non-SUSE machines on upgrade/uninstall
  • uefi support

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 08 Jul 2014 11:59:08 +0200

14.1.9. Changelog opsiconfd

opsiconfd (4.0.5.2-1) experimental; urgency=low

  • Info page: display the correct percentage if calls failed
  • Statistics: display correct result-length if returned type is dict
  • Info page: Show more info about threads if possible
  • RHEL / CentOS 7 and Fedora: Fix logrotate configuration

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 20 Oct 2014 09:38:46 +0200

opsiconfd (4.0.5.1-7) experimental; urgency=low

  • Fix for newer logrotate-versions not applied on SLES because 11SP3 provides an updated version that can handle su directive

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 19 Aug 2014 16:41:48 +0200

opsiconfd (4.0.5.1-6) experimental; urgency=low

  • Suggesting only on SLES, not everyone.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 13 Aug 2014 16:27:34 +0200

opsiconfd (4.0.5.1-5) experimental; urgency=low

  • python-rrdtool is not required but suggested.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 13 Aug 2014 16:14:13 +0200

opsiconfd (4.0.5.1-4) experimental; urgency=low

  • Lowering required debhelper version for building Ubuntu 10.04

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 14:25:31 +0200

opsiconfd (4.0.5.1-3) experimental; urgency=low

  • Re-enabling build dependency python-support for older distros.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 13:59:27 +0200

opsiconfd (4.0.5.1-2) experimental; urgency=low

  • Using dh_python instead of python-support

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 30 Jul 2014 17:29:48 +0200

opsiconfd (4.0.5.1-1) experimental; urgency=low

  • Improved info page render speed.
  • Info page: show additional information about running threads
  • Info page: display human-readable time at thread information

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 10 Jun 2014 12:36:13 +0200

14.1.10. Changelog opsi-utils

opsi-utils (4.0.5.6-2) experimental; urgency=low

  • Suse: listing /etc/opsi as directory

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 10 Oct 2014 16:49:48 +0200

opsi-utils (4.0.5.6-1) experimental; urgency=low

[ Erol Ueluekmen ]
* opsi-package-manager: new option --set-file-level added.
[ Niko Wenselowski ]
* RPM: changing the specfile to avoid conflicts
-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 10 Oct 2014 16:38:07 +0200

opsi-utils (4.0.5.5-1) testing; urgency=low

  • opsi-newprod: Fix missing newlines in postinst/preinst

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 29 Aug 2014 12:04:51 +0200

opsi-utils (4.0.5.4-1) experimental; urgency=low

  • opsi-newprod correctly copies the contents of the template-directory

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 13 Aug 2014 11:31:53 +0200

opsi-utils (4.0.5.3-2) experimental; urgency=low

  • Fix for reading the home dir.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 15:53:58 +0200

opsi-utils (4.0.5.3-1) experimental; urgency=low

  • opsi-admin: Added another try on reading the users home directory.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 17:02:03 +0200

opsi-utils (4.0.5.2-2) experimental; urgency=low

  • Make building with Fedora possible.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 15:53:19 +0200

opsi-utils (4.0.5.2-1) experimental; urgency=low

  • opsi-product-updater: small bugfix

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 03 Aug 2014 03:35:50 +0200

opsi-utils (4.0.5.1-1) experimental; urgency=low

  • opsi-newprod: New feature -t: Copy files from a template directory
  • opsi-package-manager: Now able to use -t when extracting
  • opsi-product-updater: Support for smtpuser and smtppassword to be able to use it with systems that require authentication.
  • opsi-product-updater: Support for SMTP connections that use STARTTLS
  • Debian: Recommend mysql-client as it is useful when creating backups
  • opsi-makeproductfile: new option --no-pigz to disable pigz usage
  • opsi-package-manager: Product properties are sorted by name when installing a product with "-p ask".
  • opsi-product-updater: Fix handing over the temp directory when installing a package.
  • opsi-product-updater: ProductPackageFile now uses setting "tempDir"
  • opsi-product-updater: Added inherit ProductProperties from Master-Repository
  • opsi-product-updater: Stops if unknown parameter is given on start
  • opsi-product-updater: Limit updates to specific package with "-p"

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri, 26 Jul 2014 00:03:13 +0200

14.1.11. Changelog opsi-linux-bootimage

opsi-linux-bootimage (20140919-2) stable; urgency=medium

  • small fix in spec file

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 00:56:26 +0200

opsi-linux-bootimage (20140919-1) testing; urgency=medium

  • fixing netbios nameresolution
  • advice for screen -x possibility added
  • workarround for scanning devices on HP Smart Array Controller

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri, 19 Sep 2014 10:03:09 +0200

opsi-linux-bootimage (20140819-1) experimental; urgency=medium

  • lshw updated to B.02.17

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 19 Aug 2014 02:10:29 +0200

opsi-linux-bootimage (20140811-1) experimental; urgency=medium

  • IA-32Emulation for 64 bit bootimage
  • Added opsi-utils to package dependencies

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 12 Aug 2014 12:50:47 +0200

opsi-linux-bootimage (20140729-1) experimental; urgency=low

  • Posix.py: Fix for unrecognized partition table Fix for readRotational method

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 30 Jul 2014 01:47:48 +0200

opsi-linux-bootimage (20140725-1) experimental; urgency=low

  • updated pigz to ver 2.3.1
  • updated sfdisk to ver 2.25
  • added fixed bytesPerSector problem in Posix.py
  • modprobe patched for bootimage

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Thu, 25 Jul 2014 10:21:05 +0200

opsi-linux-bootimage (20140717-1) experimental; urgency=low

  • Bases on Ubuntu Precise (12.04)
  • kernel 3.15.1
  • python-opsi 4.0.5.1
  • uefi-support added

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri, 04 Jul 2014 14:53:13 +0200

14.1.12. Changelog opsi-depotserver

opsi-depotserver (4.0.5.11-1) experimental; urgency=low

  • Only fetching the Samba init command if configuring Samba

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 13:40:03 +0200

opsi-depotserver (4.0.5.10-3) experimental; urgency=low

  • Debian-based postinst: Avoid problems with arguments possibly not executed by opsi-setup

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 21 Oct 2014 13:40:03 +0200

opsi-depotserver (4.0.5.10-2) experimental; urgency=low

  • Red Hat-familiy: added requirement samba-client for current distros

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 17 Oct 2014 14:24:41 +0200

opsi-depotserver (4.0.5.10-1) experimental; urgency=low

  • Providing a default for the name of the Samba service

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 14:54:13 +0200

opsi-depotserver (4.0.5.9-1) experimental; urgency=low

  • Fix for creating the service command

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 12:08:26 +0200

opsi-depotserver (4.0.5.8-1) experimental; urgency=low

  • Getting the Samba service name does not depend on files in /etc/init.d

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 11:01:50 +0200

opsi-depotserver (4.0.5.7-1) stable; urgency=low

  • opsi-setup: changed restarting services over service calls instead of using init-scripts directly.

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 15:26:16 +0200

opsi-depotserver (4.0.5.6-3) experimental; urgency=low

  • Removed automatic update of mysql-backend.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 08 Sep 2014 12:37:51 +0200

opsi-depotserver (4.0.5.6-2) testing; urgency=medium

  • small fix in postinst routine of package.

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Sat, 23 Aug 2014 04:44:07 +0200

opsi-depotserver (4.0.5.6-1) experimental; urgency=medium

  • --auto-configure-samba fix for executebit problem even if opsi_depot-Shareconfig already exists.

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 17 Aug 2014 13:42:03 +0200

opsi-depotserver (4.0.5.5-1) experimental; urgency=low

  • --auto-configure-dhcpd does not fail on missing file

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 17:31:12 +0200

opsi-depotserver (4.0.5.4-1) experimental; urgency=low

  • Workaround for getopt not correctly reading in JSON objects.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 12:29:21 +0200

opsi-depotserver (4.0.5.3-1) experimental; urgency=low

  • Renewing a certificate automatically sets rights on file

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 10:39:18 +0200

opsi-depotserver (4.0.5.2-1) experimental; urgency=low

  • Fix in samba4 detection

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 03 Aug 2014 00:56:54 +0200

opsi-depotserver (4.0.5.1-1) experimental; urgency=low

  • Using OPSI.Util.Task.ConfigureBackend.MySQL
  • Samba4 Fix
  • RHEL / CentOS: Running --auto-configure-dhcp grants rights to opsi administrator group on /etc/dhcp
  • Create configuration item "clientconfig.dhcpd.filename" on update
  • Using OPSI.Util.Task.ConfigureBackend.ConfigurationData

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 30 May 2014 11:48:09 +0200

14.1.13. Changelog opsi-atftp

opsi-atftp (0.7.dfsg-4) stable; urgency=medium

  • debian/compat added
  • --enable-debug added

    -- Erol Ueluekmen <e.ueluekmen@uib.de>  Sat, 23 Aug 2014 04:26:11 +0200

14.1.14. Changelog opsi4ucs

opsi4ucs (4.0.5.5-4) experimental; urgency=low

  • Using newer version of Debhelper

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 24 Oct 2014 11:50:09 +0200

opsi4ucs (4.0.5.5-3) experimental; urgency=low

  • Changed filename of Configed icon

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 24 Oct 2014 10:47:20 +0200

opsi4ucs (4.0.5.5-2) experimental; urgency=low

  • UCS 3.2: Integration in administration overview page

    -- Niko Wenselowski <n.wenselowski@uib.de>  Thu, 23 Oct 2014 14:55:31 +0200

opsi4ucs (4.0.5.5-1) experimental; urgency=low

  • Only fetching the Samba init command if configuring Samba

    -- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 13:51:46 +0200

opsi4ucs (4.0.5.4-2) experimental; urgency=low

  • Make use of OPSI.System.Posix.getSambaServiceName
  • Changed Samba4 detection to work on all UCS 3.x

    -- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 17 Oct 2014 14:57:54 +0200

opsi4ucs (4.0.5.3-1) experimental; urgency=low

  • 99opsi4ucs.inst: fix detection of Samba 4 and also work on UCS 3.2

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 15 Sep 2014 14:01:49 +0200

opsi4ucs (4.0.5.2-1) experimental; urgency=low

  • --auto-configure-dhcpd does not fail on missing file

    -- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 17:33:00 +0200

opsi4ucs (4.0.5.1-1) experimental; urgency=low

  • Using OPSI.Util.Task.ConfigureBackend.MySQL
  • Create configuration item "clientconfig.dhcpd.filename" on update
  • Using OPSI.Util.Task.ConfigureBackend.ConfigurationData
  • Renewing a certificate automatically sets rights on file
  • Workaround for getopt not correctly reading in JSON objects.

    -- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 10:51:18 +0200

14.1.15. Changelog opsi-swaudit

swaudit (4.0.5-1) stable; urgency=low

  • Fix writing to long entries in sub_create_hash4 by adding to all string values something like "name="+strPart($name$,"1","99")
  • codecleanup
  • changelog to control file

    -- detlef oertel <d.oertel@uib.de>  Fri, 01 Aug 2014 15:00:00 +0100

14.1.16. Changelog opsi-template

opsi-template (4.0.5-1) stable; urgency=low

  • setup*.*: fix: ALLUSERS=1
  • require opsi-winst 4.11.4
  • Set $LogDir$ = "%opsiLogDir%"
  • all renamed from *.ins to *.opsiscript
  • moved 64bit, 3264bit, short (with include) and delsub for multi msi to subfolders
  • new property dummy_prop

    -- detlef oertel <d.oertel@uib.de>  Mon, 03 Nov 2014 16:01:53 +0200