microsoft/pal

Platform Abstraction Layer (both SCXCoreLib and SCXSystemLib)

pal

The PAL is a Platform Abstraction Layer that is used in a variety of projects. The PAL allows for easy compatibility between many different flavors of UNIX/Linux, including AIX 6.1 and later, HP/UX 11.31 and later, Solaris 5.10 and later, and most versions of Linux as far back as RedHat 5.0, SuSE 10.1, and Debian 5.0.

The PAL has two primary components:

• SCXCoreLib
• SCXSystemLib

Testing strategy is discussed here.

SCXCoreLib

SCXCoreLib provides portable services for:

• atomic handling
• UNIX conditions
• directory lookup
• file handling (reading/writing/modifying)
• ref-counted handle mechanism to release on last use
• common logging framework
• marshalling/unmarshalling
• DNS name resolution
• pocess launching/controlling
• regular expressions
• singletons
• threading
• time handling
• other various functions

The above list is not intended to be all-inclusive. Features are added to the PAL as necessary.

SCXSystemLib

SCXSystemLib primarily returns statistical information for products like SCXcore and SCXcm, and other omi providers. This subsystem primarily follows the CIM module (enumerate a set of instances, get detailed information on a specific instance).

Primary enumeration information is supported for:

• bios
• computer system
• cpu statistics
• cpu property information
• disk information
• file system information
• installed software
• memory information
• network configuration
• network routing information
• operating system information
• process information
• processor information

This component tends to be highly system specific, and may run on fewer systems than SCXCoreLib, above.

Testing Strategy

The PAL has a fair number of unit tests. Unit tests were written with both dependency injection, and to a lesser extent, mocking in mind. By using dependency injection, we can control system dependencies well and specifically test code fragments even if unit tests are run on a system without necessary hardware configuration.

Examples for dependency injection include:

• CPU handling: See class CPUPALTestDependencies and how it provides special /proc/cpuinfo files for dependency injection purposes, regardless of how the physical machine is actually configured.
• Disk handling: See bug* files and how associated code handles those files.

There is also a very simplistic example of dependency injection in the bash script GetLinuxOS.sh, tested by getlinuxos_test.cpp. In this example, GetLinuxOS.sh is tested for proper platform handling regardless of the actual platform that the test is running on.

Code of Conduct

This project has adopted the [Microsoft Open Source Code of Conduct] (https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ] (https://opensource.microsoft.com/codeofconduct/faq/) or contact [email protected] with any additional questions or comments.

pal's Issues

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Errors when using Python 3

Error when using Python 3:

Traceback (most recent call last):
  File "/home/ubuntu/a_latest/build-omi-script-provider/pal/installer/InstallBuilder/installbuilder.py", line 3, in <module>
    import datafileparser
  File "/home/ubuntu/a_latest/build-omi-script-provider/pal/installer/InstallBuilder/datafileparser.py", line 310
    sectionPriority = m.group(1)
    ^
IndentationError: expected an indented block

and

Traceback (most recent call last):
  File "/home/ubuntu/a_latest/build-omi-script-provider/pal/installer/InstallBuilder/installbuilder.py", line 4, in <module>
    import linuxrpm
  File "/home/ubuntu/a_latest/build-omi-script-provider/pal/installer/InstallBuilder/linuxrpm.py", line 2, in <module>
    import scxutil
  File "/home/ubuntu/a_latest/build-omi-script-provider/pal/installer/InstallBuilder/scxutil.py", line 21
    print "Symbolic link: " + srcname + " -> " + dstname
                          ^
SyntaxError: Missing parentheses in call to 'print'

In Python 3, mixing tabs with spaces is a syntax error.
Also, it's required for print to have parenthesis around the string which will be printed.

None of these changes affect Python 2 in any way.

Path containing whilespaces

We are facing this bug in OMSAgent just when we added nokogiri library. Because nokogiri has a dependency on mini_portile2 gem that has 2 filepaths containing whitespaces:

mini_portile/test/assets/patch 1.diff
mini_portile/test/assets/test mini portile-1.0.0/

I can reproduce it by including a filename with whitespace in Build-OMS-Agent-for-Linux/omsagent/installer/datafiles/ruby.data :

${{RUBY_DEST}}/lib/ruby/gems/2.4.0/doc/my test.txt; ${{RUBY_DEST}}/lib/ruby/gems/2.4.0/doc/my test.txt;; 644; root; root

Error:

root@abder-pad:~/OMS/Build-OMS-Agent-for-Linux/omsagent/build# python /root/OMS/Build-OMS-Agent-for-Linux/pal/installer/InstallBuilder/installbuilder.py \
 --BASE_DIR=/root/OMS/Build-OMS-Agent-for-Linux/omsagent \
 --TARGET_DIR=/root/OMS/Build-OMS-Agent-for-Linux/omsagent/target/Linux_UBUNTU_18.04_x64_64_Debug \
 --INTERMEDIATE_DIR=/root/OMS/Build-OMS-Agent-for-Linux/omsagent/intermediate/Linux_UBUNTU_18.04_x64_64_Debug/installer_tmp \
 --STAGING_DIR=/root/OMS/Build-OMS-Agent-for-Linux/omsagent/intermediate/Linux_UBUNTU_18.04_x64_64_Debug/staging \
 --BUILD_TYPE=Debug \
 --BUILD_CONFIGURATION=Linux_UBUNTU_18.04_x64_64_Debug \
 --RUBY_INT=intermediate/Linux_UBUNTU_18.04_x64_64_Debug/ruby \
 --RUBY_ARCH=x86_64-linux \
 --RUBY_ARCM=x86_64-linux \
 --PFARCH=x64 \
 --PFDISTRO=UBUNTU \
 --PFMAJOR=18 \
 --PFMINOR=04 \
 --VERSION=1.8.1 \
 --RELEASE=370 \
 --VERSION_IDENT="20190206 Developer_Build" \
 --DATAFILE_PATH=/root/OMS/Build-OMS-Agent-for-Linux/omsagent/installer/datafiles \
 --OUTPUTFILE=omsagent-1.8.1-370.ubuntu.18.x64 \
 base_omsagent.data linux.data ruby.data linux_dpkg.data

chown: cannot access '/root/OMS/Build-OMS-Agent-for-Linux/omsagent/intermediate/Linux_UBUNTU_18.04_x64_64_Debug/staging/opt/microsoft/omsagent/ruby/lib/ruby/gems/2.4.0/gems/mini_portile2-2.4.0/test/assets/test': No such file or directory
chown: cannot access 'mini': No such file or directory
chown: cannot access 'portile-1.0.0/configure': No such file or directory
Unable to chown /root/OMS/Build-OMS-Agent-for-Linux/omsagent/intermediate/Linux_UBUNTU_18.04_x64_64_Debug/staging/opt/microsoft/omsagent/ruby/lib/ruby/gems/2.4.0/gems/mini_portile2-2.4.0/test/assets/test mini portile-1.0.0/configure.

As a workaround, I've removed these 2 paths since its only related to testing, but we need to fix this issue.

Typo in GetOsLinux.sh

s/Softare/Software/

Beware https://github.com/Microsoft/pal/blob/master/test/code/scxsystemlib/common/getlinuxos_test.cpp
tests for this typo too.