Table of Contents
List of Figures
/home/partimg
.List of Tables
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).
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
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.
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:
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.
Windows netboot products
opsi-winst / opsi-script (4.11.4.10):
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:
getValueFromFile(
<key string>, <file name>)
//since 4.11.4.4 [W/L]
getValueFromFileBySeparator(
<key string>,<separator string>,<file name>)
//since 4.11.4.4 [W/L]
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 !):
reencodestr(
<str> , <from>, <to> )
reencodestrlist(
<strlist> , <from>, <to> )
Show Activity:
winbatch
sections with /timeout
a progressbar will show the time to timeout
AutoActivityDisplay
= (true/false) default=false; if true shows a marquee (endless) progressbar while winbatch/dosbatch sections are running.
/showoutput
: shows a windows with the continuous output of the command while running
Miscellaneous:
saveTextFile(
<list>, < filename>)
//since 4.11.4.4 [W/L]
shellCall(
<cmd> )
; returns the output of (sysnative) shell with cmd
IncludeLog
with additional encoding parameter
strLoadTextFile (
<filename> )
LineContaining_ExistsIn(
<string>, <file name> )
Miscellaneous products:
opsi-configed:
opsi-client-agent:
KNOWN BUGS:
KNOWN PROBLEMS:
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.
This chapter lists the discontinued versions. For various reasons, these distribution versions will not be supported by opsi anymore.
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).
With opsi v 4.0.5 the following products are not supported any more:
They are replaced by the new product opsi-clonezilla (for details see the related chapter).
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.
During the opsi-depotserver upgrade you may be asked again for information about a SSL certificate preparation.
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
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
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.
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.
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:
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).
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.
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.
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:
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.
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.
Technical precondition is opsi 4.0.5 with following packet versions:
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.
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:
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
.
The following properties for controlling the Linux installation are available with all netboot products:
askbeforeinst
:architecture
:system_partition_size
:swap_partition_size
: +size of the swap partition. (default=2000M)
data_partition_create
:data_partition_preserve
:language
:console_keymap
:timezone
:root_password
:user_password
:install_opsi_server
:online_repository
:opsi_online_repository
:proxy
:http://<ip>:<port>
(default='')
additional_packages
:wget_and_execute
:install_opsi-client-agent
:release
:setup_after_install
: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.
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.
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.
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
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
kernel_modules
suse_register
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
.false
the property local_repositories
must contain at least one suitable repository server.
productkey
email:productkey
(if no license management used).
local_repositories
The property online_repository
is omitted.
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.
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.
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:
opsiclientd
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:
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.:
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.:
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.
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 - )
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
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:
apt-get
, zypper
or yum
)
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 $?
Here some localboot products that are part of the standard opsi Linux support.
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:
Fedora:
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.
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:
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.
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.
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.
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:
Instructions for installation and use of local deb packets:
German:
English:
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:
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.
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:
partitioning with GPT and additional partitions for the bootloader:
Links :
http://de.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
GPT (GUID Partition Table) id the follow-up for the previous MBR partition tables. GPT is part of the UEFI specification.
Basically GPT can be used without UEFI. But UEFI depends on GPT. With UEFI there are up to two additional partitions:
Links :
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.
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.
The opsi support for UEFI is based on several components:
opsi-uefi-netboot
:uefinetbootlabel
or it is a non UEFI client, just a reboot is triggered.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
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 Twist | MS-Surface | Dell 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
.
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.
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>
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
Technical preconditions are opsi 4.0.3 with the following package and product versions:
or opsi 4.0.5 with the following package and product versions:
Table 11.2. Needed product and package versions
opsi packet | version |
---|---|
opsi-linux-bootimage | >= 20140805-1 |
opsi-clonezilla | >= 4.0.5-1 |
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.
We have combined the clonezilla scrips with the opsi-linux-bootimage to generate the following benefits:
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.
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.
runcommand
to /opt/drbl/sbin/ocs-live
or ocs-live
using opsi >= 4.0.5. This is the interactive mode of clonezilla.
/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
.
The mounted partition will be displayed:
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.
Now you have to choose which basic operation you like to run. In this manual we discuss only the following operations:
Here we show (as an example for similar operations) the additional dialogs you will get in the savedisk expert mode.
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.
Figure 11.10. Action after cloning (use the default -p true, the reboot is triggered by the opsi bootimage).
By setting the desired command as the product property runcommand
opsi-clonezilla is switched to the non interactive mode.
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).
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
.
At opsi-clonezilla version 4.0.5-2 with bootimage Version 20140819-1 there are problems while imaging computers that running in UEFI mode.
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:
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:
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:
Example:
ocs-sr --use-ntfsclone -z3 savedisk IMAGE1 hda
ocs-sr --use-ntfsclone -z3 saveparts IMAGE2 "hda1 hda2"
ocs-sr -g auto restoredisk IMAGE1 hda
ocs-sr -g auto restoreparts IMAGE2 "hda1 hda2"
ocs-sr -x
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).
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:
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.
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:
The workstation is being used with a static partition table of three or four partitions.:
opsi-local-image-prepare
according to the particular property state.
opsi-local-image-prepare
according to the particular property state.
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.
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.
opsi-local-image-prepare
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.
Use this product only for the initial preparation of the disc for it deletes all existing images.
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
opsi-local-image-win7
nt123
.
opsi-local-image-win7-x64
nt123
.
opsi-local-image-win8
nt123
.
opsi-local-image-win8-x64
nt123
.
opsi-local-image-win81
nt123
.
opsi-local-image-win81-x64
nt123
.
The following products have special properties for opsi-local-image:
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
).
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
:architecture
:additional_packages
:language
:console_keymap
timezone
:online_repository
proxy
:http://<ip>:<port>
(default = '')
backup_after_install
setup_after_install
wget_and_execute
:release
:install_opsi-client-agent
:
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
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
imagefiles_list
.
imagefiles_list
method
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
.rsync-partclone-image
fails, the restore will continue automatically by using the method partclone-image-restore
.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
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
opsi-local-image-delete
This product deletes the image given by the product property imagefile from the backup partition
imagefile
opsi-local-image-backup-starter
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:setup
:opsi-local-image-restore
opsi-local-image-backup-starter
This results in the following process order:
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
hostGroupId, productId, actionRequest
setProductPropertyForHostGroup
productId propertyId propertyValue hostGroupId
getPossibleImagefileValuesForHostGroup
groupId
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
.
The product opsi-local-image-prepare
first generates the required static partitioning.
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.
Per default after the installation they will be backuped as 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
.
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.
The backup partion is (with MBR BIOS without data partition) the third partition of disc one.
It contains:
master.log
with information about all image operations performed. This logfile is transfered to the bootimage logs.
opsi-local-image-ubuntu
: 3.6G
opsi-local-image-winxp
: 6.4G
opsi-local-image-win7
: 9.4G
opsi-local-image-win7-x64
: 13G
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.
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
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.
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 = '')
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
.
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.
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:
start_after_capture
During the second phase WinPE starts and executes the actual capture process. In detail:
append
mode: check whether an image with this name exists and in case deletge this existing image.
Imagenames
of the target product, so that the new created image can be selected for installation.
start_after_capture
to setup.
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.
For a helpful manual for creating an own Ubuntu proxy refer to:
http://wiki.ubuntuusers.de/Lokale_Paketquellen/Apt-Cacher-ng
http://www.gambaru.de/blog/2011/10/26/apt-cacher-ng-ein-proxy-server-fur-debian-und-ubuntu/
The basic steps of software packaging and distribution are:
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.
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:
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.
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.
The opsi Setup Detector package contains the following files:
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:
The menu on the upper left contains the following options:
The menu option File opens a sub menu with:
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.
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.
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.
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:
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).
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:
Signature Advanced+MSI: for detection of an Advanced+MSI setup, the EXE file is scanned for the marker:
name="microsoft.windows.advancedinstallersetup
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:
Signature Inno Setup: for detecting a setup as Inno Setup, the EXE file is scanned for the marker:
<description>inno setup</description>
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:
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).
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:
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.
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:
Signatur NSIS: for detecting a NSIS Setup, the EXE file will be scanned for the marker:
Nullsoft.NSIS.exehead ... Nullsoft Install System
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:
Left of the Create opsi Packet button are three available options to specify the operation of the button:
For installation, configuration and instructions for the Community Project opsi Packet Builder see https://forum.opsi.org/viewforum.php?f=22
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
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
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
gzip compression is no default
-- rupert roeder <roeder@bonifax.uib.local> Thu, 13 Mar 2014 14:10:37 +0100
opsi-client-agent (4.0.5.1-8) stable; urgency=low
— 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
— 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
— 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
— 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
— 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
— 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
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
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
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
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
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
loginblocker logfile written to dir opsi.org\log
-- Miriam Michaelis <m.michaelis@uib.de> Tue, 18 Mar 2014 15:00:00 +0100
opsi-winst/opsi-script (4.11.4.10) stable; urgency=low
— 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
— 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
— 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
— 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
— 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
— 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
— 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
— 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
— 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
— Detlef Oertel <d.oertel@uib.de> Tue, 30 Jul 2013:15:00:00 +0200
opsi-winst/opsi-script (4.11.4) stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 30 Apr 2012:15:00:00 +0200
windows (4.0.5-4) stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Thu, 16 Oct 2014:15:00:00 +0200
windows (4.0.5-3) stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200
windows (nt6) (4.0.5-2) stable; urgency=low
— 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
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
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
Debian
debian-4.0.5-4 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200
debian-4.0.5-3 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200
debian-4.0.5-2 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 26 Aug 2014:15:00:00 +0200
debian-4.0.5-1 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 23 Jun 2014:15:00:00 +0200
debian-4.0.4-4 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Fri, 20 May 2014:15:00:00 +0200
debian-4.0.4-3 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Fri, 02 May 2014:15:00:00 +0200
debian_4.0.4-2 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 17 Mar 2014:15:00:00 +0200
debian_7.02 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 10 Dec 2013:15:00:00 +0200
debian_6-5 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 22 Apr 2013:15:00:00 +0200
debian-4.0r3-1 testing; urgency=low
Ubuntu
ubuntu-4.0.5-7 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Wed, 22 Oct 2014:15:00:00 +0200
ubuntu-4.0.5-6 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 22 Sep 2014:15:00:00 +0200
ubuntu-4.0.5-5 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200
ubuntu-4.0.5-4 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 26 Aug 2014:15:00:00 +0200
ubuntu-4.0.5-3 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Fri, 15 Aug 2014:15:00:00 +0200
ubuntu-4.0.5-2 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 23 Jun 2014:15:00:00 +0200
ubuntu-4.0.5-1 stable; urgency=low
— 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
— Detlef Oertel <d.oertel@uib.de> Fri, 02 May 2014:15:00:00 +0200
ubuntu-4.0.4-3 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 18 Mar 2014:15:00:00 +0200
ubuntu-4.0.4-2 UNRELEASED; urgency=low
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
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
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
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
integrated 64bit opsi-linux-bootimage
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
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
openSUSE
opensuse13-1_13.01-6 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 21 Oct 2014:15:00:00 +0200
opensuse13-1_13.01-5 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Fri, 26 Sep 2014:15:00:00 +0200
opensuse13-1_13.01-4 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 28 Jul 2014:15:00:00 +0200
opensuse13-1_13.01-3 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200
opensuse13-1_13.01-2 UNRELEASED; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 18 Feb 2014:15:00:00 +0200
opensuse13-1_13.01-1 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 9 Dec 2013:15:00:00 +0200
opensuse12-3_12.03-5 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 21 Oct 2014:15:00:00 +0200
opensuse12-3_12.03-4 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Fri, 26 Sep 2014:15:00:00 +0200
opensuse12-3_12.03-3 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200
opensuse12-3_12.03-2 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 18 Feb 2014:15:00:00 +0200
opensuse12-3_12.03-1 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 9 Dec 2013:15:00:00 +0200
opensuse-12.03-2 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 26 Sep 2013:15:00:00 +0200
opensuse-12.03-1 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 24 Sep 2013:15:00:00 +0200
opensuse-10.03-1 experimental; urgency=low
sles11sp3
sles11sp3-11.3-10 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200
sles11sp3-11.3-9 stable ; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 09 Sep 2014:15:00:00 +0200
sles11sp3-11.3-8 stable ; urgency=low
— Detlef Oertel <d.oertel@uib.de> Wed, 20 Aug 2014:15:00:00 +0200
sles11sp3-11.3-7 stable ; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 20 Jan 2014:15:00:00 +0200
sles11sp3-11.3-6 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Wed, 15 Jan 2014:15:00:00 +0200
sles11sp3-11.3-5 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Thu, 09 Jan 2014:15:00:00 +0200
sles11sp3-11.3-4 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Wed, 18 Dec 2013:15:00:00 +0200
sles11sp3-11.3-3 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Thu, 12 Dec 2013:15:00:00 +0200
sles11sp3-11.3-2 experimental; urgency=low
— Erol Ueluekmen <e.ueluekmen@uib.de> Tue, 29 Oct 2013:10:00:00 +0200
sles11sp3-11.3-1 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 28 Oct 2013:15:00:00 +0200
centos65
centos65_6.5-3 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 05 Aug 2014:15:00:00 +0200
centos65_6.5-2 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 28 Apr 2014:15:00:00 +0200
centos65_6.5-1 experimental; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 3 Feb 2014:15:00:00 +0200
Fedora 20
fedora_20_20-4 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200
fedora_20_20-3 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Tue, 22 Apr 2014:15:00:00 +0200
fedora_20_20-1 stable; urgency=low
— Detlef Oertel <d.oertel@uib.de> Mon, 23 Dec 2013:15:00:00 +0200
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
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
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
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
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
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
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
initial
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:\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
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
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
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
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
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
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
— 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
— 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
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
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
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
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
— 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
— 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
— 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
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
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
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
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
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
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
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
initial
opsi-local-image-sysprep
opsi-local-image-sysprep (4.0.5.1-1) stable; urgency=low
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 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
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
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
— detlef oertel <d.oertel@uib.de> 16 Dec 2013
opsi-local-image-win7 (4.0.3.2-1) stable; urgency=low
— 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
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
— detlef oertel <d.oertel@uib.de> 16 Dec 2013
opsi-local-image-ubuntu32 (4.0.3.2-2) stable; urgency=low
— detlef oertel <d.oertel@uib.de> 24 Sep 2013
opsi-local-image-ubuntu32 (4.0.3.2-1) stable; urgency=low
— detlef oertel <d.oertel@uib.de> 01 Aug 2013
opsi-local-image-ubuntu32_4.0.3-3 stable; urgency=low
— uib GmbH <info@uib.de> Mon, 1 Jul 2013 13:30:20 +0000
opsi-local-image-ubuntu32_4.0.3-2 stable; urgency=low
— uib GmbH <info@uib.de> Wed, 17 Apr 2013 13:30:20 +0000
opsi-local-image-ubuntu32_4.0.3-1 testing; urgency=low
— Detlef Oertel <d.oertel@uib.de> Fri, 01 Feb 2013:15:00:00 +0200
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
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
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
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
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
OPSI.Util.Repository: workarround timing problem after reconnect network adapter
-- Erol Ueluekmen <e.ueluekmen@uib.de> Thu, 28 Jul 2014 23:51:00 +0200
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
uefi support
-- Erol Ueluekmen <e.ueluekmen@uib.de> Tue, 08 Jul 2014 11:59:08 +0200
opsiconfd (4.0.5.2-1) experimental; urgency=low
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
Info page: display human-readable time at thread information
-- Niko Wenselowski <n.wenselowski@uib.de> Tue, 10 Jun 2014 12:36:13 +0200
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-product-updater: Limit updates to specific package with "-p"
-- Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 26 Jul 2014 00:03:13 +0200
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
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
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
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
uefi-support added
-- Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 04 Jul 2014 14:53:13 +0200
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.ConfigurationData
-- Niko Wenselowski <n.wenselowski@uib.de> Fri, 30 May 2014 11:48:09 +0200
opsi-atftp (0.7.dfsg-4) stable; urgency=medium
--enable-debug added
-- Erol Ueluekmen <e.ueluekmen@uib.de> Sat, 23 Aug 2014 04:26:11 +0200
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
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
Workaround for getopt not correctly reading in JSON objects.
-- Niko Wenselowski <n.wenselowski@uib.de> Tue, 05 Aug 2014 10:51:18 +0200
swaudit (4.0.5-1) stable; urgency=low
changelog to control file
-- detlef oertel <d.oertel@uib.de> Fri, 01 Aug 2014 15:00:00 +0100
opsi-template (4.0.5-1) stable; urgency=low
new property dummy_prop
-- detlef oertel <d.oertel@uib.de> Mon, 03 Nov 2014 16:01:53 +0200