Comment trouver le numéro du service client Orange Pro

Note : si tout ce que vous cherchez c’est le numéro du service client Orange Pro, à la date du 15/10/2021 c’est le 3901. Voir en fin d’article pour plus de détails. La semaine dernière ma connexion internet est tombée en panne. La petite lumière qui indique la réception fibre est rouge, ce qui signifie que le signal n’arrive plus jusque chez moi. Ayant eu une bonne expérience du service client Orange par le passé, je me dirige confiant vers la page de support.

Using AutoPkg to create an installer package for SAP GUI

I’ve previously posted guides on how to manually package SAP GUI:

However it’s also possible to automate creating a SAP GUI installer package using AutoPkg. To do this, you’ll need the following:

  1. AutoPkg
  2. The SAP GUI recipes from the rtrouton-recipes repo
  3. The latest SAP GUI installer application’s disk image
  4. A SAP GUI templates.jar file (optional)

For more details, please see below the jump.

The AutoPkg recipes I’ve written will need the following information provided:

  • SAP GUI’s numeric information
  • SAP GUI’s alphanumeric information
  • SAP GUI’s application bundle identifier information

None of this information is available from the installer application, so you’ll need to provide it to AutoPkg using a com.sapgui.identifier.plist file which will be included along with the latest SAP GUI installer application’s disk image. Please see below for how to gather this information.

Preparing SAP GUI for AutoPkg

1. Copy the latest SAP GUI installer application’s disk image to a test Mac or virtual machine.

2. Mount the disk image and launch the SAP GUI for Java Installer installer application on the test Mac or virtual machine.

Screen Shot 2021 07 22 at 2 16 27 PM

3. Follow the prompts to install.

Screen Shot 2021 07 22 at 2 16 55 PM

Screen Shot 2021 07 22 at 2 17 20 PM

Screen Shot 2021 07 22 at 2 17 32 PM

Screen Shot 2021 07 22 at 2 17 56 PM

4. Once installed, run the following command to get SAP GUI’s alphanumeric version.

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" NSHumanReadableCopyright | awk '{print $2$3$4}'

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" NSHumanReadableCopyright| awk '{print $2$3$4}'

Screen Shot 2021 07 22 at 2 34 18 PM

5. Once you have the alphanumeric version, run the following command to get SAP GUI’s numeric version.

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" CFBundleShortVersionString

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" CFBundleShortVersionString

Screen Shot 2021 07 22 at 2 35 47 PM

6. Once you have both versions, run the following command to get SAP GUI’s bundle identifier:

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" CFBundleIdentifier

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" CFBundleIdentifier

Screen Shot 2021 07 22 at 2 45 12 PM

7. Open Terminal and run the following command to create a com.sapgui.identifier.plist file with the alphanumeric version information for SAP GUI:

defaults write /path/to/com.sapgui.identifier AlphanumericVersionString version_info_goes_here

For example, if the SAP GUI alphanumeric version is 7.70rev2, run the following command to create a com.sapgui.identifier.plist file on the Desktop:

defaults write $HOME/Desktop/com.sapgui.identifier AlphanumericVersionString 7.70rev2

Screen Shot 2021 07 22 at 2 49 14 PM

8. Run the following command to add the numeric version information for SAP GUI to the com.sapgui.identifier.plist file:

defaults write /path/to/com.sapgui.identifier CFBundleShortVersionString version_info_goes_here

For example, if the SAP GUI numeric version is 770.4.200, run the following command

defaults write $HOME/Desktop/com.sapgui.identifier CFBundleShortVersionString 770.4.200

Screen Shot 2021 07 22 at 2 59 28 PM

9. Run the following command to add the bundle identifier information for SAP GUI to the com.sapgui.identifier.plist file:

defaults write /path/to/com.sapgui.identifier CFBundleIdentifier bundle_identifier_info_goes_here

For example, if the SAP GUI bundle identifier is com.sap.platin, run the following command

defaults write $HOME/Desktop/com.sapgui.identifier CFBundleIdentifier com.sap.platin

Screen Shot 2021 07 22 at 2 58 32 PM

10. Once the com.sapgui.identifier.plist file is created and populated with the version and bundle identifier information, copy it to a convenient location along with the latest SAP GUI installer application’s disk image.

11. If you’re planning to include a templates.jar file with the SAP GUI installer, copy the templates.jar file to the same location.

Screen Shot 2021 06 18 at 12 12 51 PM

12. Create a .zip file of the following files:

  • corp.sap.sapgui.identifier.plist
  • Latest SAP GUI installer application’s disk image
  • templates.jar (if applicable)

For this example, I’m going to use the following filename for the .zip file:

latestsapgui.zip

This .zip file will be what’s used by AutoPkg to create the SAP GUI installer package.

Screen Shot 2019 10 09 at 11 30 35 AM

 

Using the AutoPkg recipes

To accomodate the fact that some folks will have a templates.jar file which they want to include and some folks won’t, I’ve written two sets of .pkg recipes:

  • SAPGUIWithTemplate.pkg – Use when you’re using a templates.jar file
  • SAPGUIWithoutTemplate.pkg – Use when you’re not using a templates.jar file

Both sets of recipes share a common SAPGUI.download recipe.

SAP GUI does not have a publicly accessible download link, so there are two options available for adding the .zip file you created earlier to your AutoPkg workflow:

1. Posting the .zip file to a web server for download.

You can upload the .zip file to a web server or other online storage location which AutoPkg can download files from. This is my preferred method because you can set the download URL in an AutoPkg override. Once that’s done, you just need to replace the .zip file on the web server when a new version of SAP GUI comes out. The next time it’s run, AutoPkg will download the new .zip file and handle the rest automatically.

2. Using AutoPkg’s -p option.

AutoPkg includes an -p option for specifying a file for input, in place of downloading from a URL.

Screen shot 2015 01 26 at 7 36 26 am

For example, if you wanted to run the SAPGUIWithTemplate.pkg recipe and use a .zip file stored locally on your Mac, you would use the following command to run an AutoPkg override of the SAPGUIWithTemplate.pkg recipe and specify a .zip file named latestsapgui.zip:

autopkg run local.pkg.SAPGUIWithTemplate -p /path/to/latestsapgui.zip

Once you’ve sorted out how you’re adding the .zip file you created to your AutoPkg workflow, you should be able to use these recipes to create SAP GUI installer packages for use in your own environment.

For those who want to use code signing to sign the SAP GUI installers created by AutoPkg, I’ve also created the following .sign recipes:

SAPGUIWithTemplate.sign – Use when you’re using a templates.jar file
SAPGUIWithoutTemplate.sign – Use when you’re not using a templates.jar file

Each .sign recipe uses the appropriate .pkg recipe as a parent recipe.

Installer package identifiers and the mystery of the missing Java 11 files

As part of developing new AutoPkg recipes to support SapMachine‘s new Long Term Support (LTS) distribution for Java 17, I ran into a curious problem when testing. When I ran the SapMachine Java 17 LTS installer that was being generated by AutoPkg, I was seeing the following behavior:

  • SapMachine Java 17 LTS is installed by itself – no problem
  • SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed – no problem
  • SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed – SapMachine Java 11 LTS is removed, only SapMachine Java 17 LTS is installed now.

I double-checked the preinstall script for the SapMachine Java 17 LTS installer. It is supposed to remove an existing SapMachine Java 17 LTS installation with the same version info, but it should not have also been removing SapMachine Java 11 LTS. After a re-review of the script and additional testing, I was able to rule out the script as the problem. But what was causing this behavior? Also, why was it happening in this order?

  • SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed

But not this order?

  • SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed

The answer was in how the package’s package identifier was set up. For more details, please see below the jump.

When I was writing the AutoPkg .pkg recipes for SapMachine Java 17 LTS, I used the existing SapMachine Java 11 LTS .pkg recipe as a template. Included with that recipe was the following:

<key>id</key>
<string>net.java.openjdk.sapmachine</string>

view raw
gistfile1.txt
hosted with ❤ by GitHub

For AutoPkg’s PkgCreator processor, this defines the package identifier.

I didn’t change that. That was a mistake, because that meant that Apple’s Installer was going to see SapMachine Java 17 LTS as an upgrade install for an existing SapMachine Java 11 LTS installation. Why is this important?

When macOS’s Installer does an upgrade install, it does the following:

  1. Consults its store of existing installer package receipts.
  2. Identifies if it has a receipt by a previous installer with a matching package identifier. If multiple receipts are found, the latest installed is used.
  3. Uses the Bill of Materials (BOM) stored with the receipt to generate a list of files which are in the receipt’s BOM and are not part of the new installer’s BOM.
  4. Removes the files in question.
  5. Adds the files from the current installer.

Note: Files added, removed or changed outside of the main installation process will not be included in the BOM. Since these files are not included in the BOM’s listing, the installer process will not move, change or delete these files. Examples of files not included or tracked by the BOM would be files added or moved by an installer package’s preinstall or postinstall scripts.

From Installer‘s point of view, the two packages were identified this way:

SapMachine Java 11 LTS

  • Identifier: net.java.openjdk.sapmachine
  • Version: 11.xx.xx

SapMachine Java 17 LTS

  • Identifier: net.java.openjdk.sapmachine
  • Version: 17.xx.xx

That meant that, on a Mac where SapMachine Java 11 LTS had been installed previously using an installer package with the net.java.openjdk.sapmachine package identifier, Installer interpreted the SapMachine Java 17 LTS install as being an upgrade for SapMachine Java 11 LTS.

In those conditions, Installer performs the following actions:

  1. Consults the existing installer package receipts.
  2. Identifies the latest version of the SapMachine Java 11 LTS receipt with a matching net.java.openjdk.sapmachine package identifier.
  3. Generates a list of the files installed by the SapMachine Java 11 LTS installer package, using the SapMachine Java 11 LTS receipt’s BOM, and identified those files which were not included in the SapMachine Java 17 LTS installer package’s BOM.
  4. Removes those files.
  5. Adds the files from the SapMachine Java 17 LTS installer.

The effect is that SapMachine Java 11 LTS’s files were automatically removed when SapMachine Java 11 LTS is installed first and then SapMachine Java 17 LTS is subsequently installed.

The fix? Make sure the SapMachine Java 17 LTS installer package has a different package identifier.

As I was using AutoPkg to build the installer package in question, I could include variables as part of the package identifier to help ensure the package identifier would be unique for each version of the SapMachine Java 17 LTS installer package.

<key>id</key>
<string>net.java.openjdk.sapmachine.universal.%version%.%BUILD_NUMBER%</string>

view raw
gistfile1.txt
hosted with ❤ by GitHub

For example, for SapMachine Java 17.35 LTS, the package identifier looks like this in the AutoPkg-created installer package:

<key>id</key>
<string>net.java.openjdk.sapmachine.universal.17.35</string>

view raw
gistfile1.txt
hosted with ❤ by GitHub

Stéréotypage

Pour les uns, je suis scriptwriter, pour d’autres, je suis coach en présentations, et encore pour d’autres, je suis designer. Mais je ne suis tout cela que pour moi ; aucun client ne conçoit que je puisse assumer tous ces rôles. Je dirais même plus : si j’essaie d’assumer tous ces rôles moi-même auprès d’un client, cela ne marche pas particulièrement bien. C’est comme ça : une fois qu’un client vous a mis dans une case, c’est très difficile de changer sa perception.

L’airtag à 15000€

Gros choc au réveil ce lundi matin : en ouvrant mon bureau, je découvre que j’ai été cambriolé durant la nuit. Bilan des courses : une dizaine de MacBook (Air et Pro), ainsi qu’un iPad, volés, perdus corps et âme. Not cool. D’autant qu’une bonne partie de ce matériel est du matériel de test de mes clients. Stress total, même si je sais que ce ne sont pas des machines contenant des données sensibles. Mais quand même, les boules, en plus du stress de savoir qu’on a été visité la nuit.

Visite de la police scientifique, puis de la police tout court en début d’après-midi, et là, je constate qu’en plus du matériel, ma sacoche contenant mes papiers, CB et autres joyeusetés a été volée. Ainsi que… mon sac à dos.

Tiens donc. Un sac à dos et une sacoche où j’ai glissé un AirTag. Lançons donc vite l’app Localiser…

Mon sac et ma sacoche ont été vus quelques heures plus tôt. Deux rues plus loin. Littéralement.

Je rappelle la police, leur indique l’emplacement, ils me préviennent que je dois me rendre sur place, et m’y rejoignent. Toujours stressé mais un peu excité, j’arrive devant le lieu où est censé se trouver mon sac. Un petit immeuble. L’app Localiser confirme : le sac est bien dans le coin ! Les policiers arrivent, et pensent que le sac se trouve dans un squat quelques mètres plus loin.

« Hmmm non m’sieur l’agent, vous connaissez peut-être pas les Airtag, mais c’est vraiment précis. Là, on me dit bien que c’est de ce côté de la rue. Essayons d’être plus précis… » J’active la fonction Localiser pour essayer d’être le plus précis possible… Le sac est sensé être là. Mais là, il n’y a que des buissons…

L’un des policiers se penche par dessus, et dit « ah oui, y’a quelque chose là-dedans, et soulève… mon sac à dos.

« Euh, dites donc, il est super lourd ce sac ».

Tu m’étonnes.

Donc mon cambrioleur a fait une légère erreur : en prenant mon sac à dos, il a aussi embarqué son AirTag. Et il a posé tous les Mac dans ce sac à dos, qu’il a déposé dans ce buisson, sans doute pour le récupérer la nuit tombée…

Malheureusement, pas de trace de ma sacoche. Mais honnêtement… c’est un moindre mal. Et je sais que j’ai eu énormément de chance…

Donc : merci l’AirTag. Sûrement un de mes meilleurs investissements de cette année. Et merci aux policiers qui ont suivi mon dossier avec attention (et qui ont été assez épatés quand je leur ai expliqué le fonctionnement des AirTags).

Quand à moi, je vais un peu mieux sécuriser mes locaux. Quand même.

Slides and video from the “AutoPkg in the Cloud” session at MacSysAdmin 2021

For those who wanted a copy of my cloud hosting for AutoPkg talk at at the MacSysAdmin 2021 conference, here are links to the slides in PDF and Keynote format.

The video of my session is available for download from here:

Pourquoi le Cloud Souverain ne peut pas être compétitif

Parce que ce concept repose sur une vision étriquée et périmée du monde. Le Cloud Souverain, c’est un Clexit, l’équivalent du Brexit, mais pour le Cloud, et en plus ça sonne moins bien. En s’isolant, le Cloud Souverain se protège de toute pression extérieure puisque la réglementation le met en situation de monopole pour ses clients. Les conséquences d’une telle situation sont faciles à prévoir : Ergonomie utilisateur déficiente, car les utilisateurs sont captifs.

Enabling full disk access for SSH on macOS Big Sur using a management profile

When connecting via SSH to a remote Mac running macOS Big Sur, Apple’s user-level privacy controls apply. You can access data in the home folder of the account you’re using to connect, but you can’t access or alter protected data in other account’s home folders.

For most use cases, this is fine. However, there may be circumstances when full disk access for SSH connections is desired. To accommodate for this, Apple added an Allow full disk access for remote users checkbox in the Remote Login settings in System Preference’s Sharing preference pane.

EnableFullDiskAccessforSSH

This setting can normally only be enabled by the logged-in user sitting at that Mac. However, there is a way to manage this with a configuration profile. For more details, please see below the jump.

I’ve written a profile to manage full disk access for SSH connections which does the following:

  • Enables the Allow full disk access for remote users checkbox in the Remote Login settings in System Preference’s Sharing preference pane
  • Enables full disk access for /usr/libexec/sshd-keygen-wrapper

The first part is mainly cosmetic. It enables the Allow full disk access for remote users checkbox, but does not actually enable full disk access for SSH. That function is handled by the second part, which are the PPPC settings to allow full disk access for /usr/libexec/sshd-keygen-wrapper.

In order to apply PPPC settings, there are some pre-requisites:

  • User Approved Mobile Device Management (UAMDM) must be enabled on the target Mac.
  • Profile must be installed by an MDM server.

Those pre-requisites also apply to deploying this profile, which is available via the link below:

https://github.com/rtrouton/profiles/tree/main/EnableFullDiskAccessforSSH

When deployed, the profile should appear similar to this in System Preference’s Profiles preference pane.

Screen Shot 2021 09 29 at 5 23 58 PM

Hat tip to poundbangbash for providing the correct PPPC settings for SSH full disk access by allowing full disk access to /usr/libexec/sshd-keygen-wrapper.

Attention à la mise à jour Big Sur depuis macOS Mojave !

Nous sommes actuellement chez Gete.Net Consulting (enfin, chez nos clients) en période de migration d’OS, et pour beaucoup, nous avons fait le choix de basculer directement de Mojave (10.14.x) vers macOS Big Sur (11.4). Pas de souci jusqu’à la semaine passée… où nous avons mis à jour notre package d’installation vers macOS 11.6.

Et là, c’est le drame…

Depuis le passage sur la version 11.6, l’installation échoue systématiquement et a une fâcheuse tendance à complètement planter les Mac, obligeant à une réinstallation complète. Nous sommes revenus sur le package d’installation 11.4, et plus de souci. Cela semble assez bien confirmé sur le Slack MacAdmins, où de nombreux administrateurs système rencontrent le même problème.

Donc, si vous devez faire un saut conséquent de version de macOS, évitez pour le moment les logiciels d’installation 11.5 et 11.6, et préférez le logiciel d’installation 11.4.

Un nouvel album de Goldorak va sortir et personne ne me dit rien

C’est LA nouvelle du siècle : une nouvelle BD de Goldorak va sortir, et personne ne m’a prévenu. Mais que fait notre gouvernement ??? À priori elle sera disponible le 15 octobre, et sur la couverture il y a les noms d’auteurs bien connus des fans de BD. Actarus a troqué son éternel pull jaune et son gilet de cowboy pour une blouse en cuir et il s’est laissé pousser la barbe.