Install4j service not started on machine reboot for Suse Enterprise Linux - install4j

We have created an application using Install4j. This application has a service, created by using "Install a Service" action, with "auto start" attribute set.(The application launcher is a "Service" type with unix option "Auto-start service for Linux packages".)
For CentOS7, CentOS6, ,RHEL7, RHEL6 platforms the service starts automatically when the system is rebooted.
For Suse Enterprise Linux 12.x series, the service could not be started on system boot up. It is working fine, when invoked manually by command "/etc/init.d/{service-name} start".
When we check for the deployed files, the service file is copied to /etc/init.d/ folder and corresponding entries K50{service-name}, S50{service-name} files created at /etc/init.d/rc2.d/, /etc/init.d/rc3.d/, /etc/init.d/rc4.d/, /etc/init.d/rc5.d/. The service is turned on by chkconfig for 2,3,4,5 run levels. But when we reboot the machine, this particular service is not even attempted in the startup process.
Please suggest.

Related

How can I copy script from Rundeck server to a brand-new Windows Server

One of the requirements is to keep remote Windows Server intact.
No third party software allowed (no WinSCP, etc).
So we configure Windows Server with WinRM and allow remote access, AllowUnencrypted=true, Auth basic=true, etc...
Then we create job and execute command on Windows server like "ifconfig" successfully.
When it comes to executing inline script or copying file - Rundeck is trying to copy script/file to remote Windows server.
By default:
plugin.script-copy.default.command=get-services
where "get-services" seems to be free-form text rather than executable.
If we want to use SCP or SSH instead, here we have problem -> Windows Server doesn't have WinSCP or SSH or Python installed by default.
Is there any way to copy/deliver script to target/remote Windows Server 2008 using embedded capabilities only (no third-party software allowed) ?
Versions:
Rundeck 2.6.2 running on Linux
Windows Server 2008 R2 Enterprise, Service Pack 1
Thank you.
You can use the WinRM plugin (AKA "Overthere WinRM"), configure it, and use the copy file step on your job workflow (keep in mind that you need the 1.3.4 WinRM plugin at least which support copy file).
You need to download the plugin and put it in Rundeck the libext directory.
Add the Windows resources.xml entry (for "Overthere" WinRM plugin):
<node name="windows" description="Windows node" tags="" hostname="192.168.1.81" osArch="x86" osFamily="windows" osName="Windows 2008R2" osVersion="2008" username="user" winrm-protocol="http" winrm-auth-type="basic" winrm-cmd="CMD" winrm-password-storage-path="keys/winpasswd"/>
Set WinRM as your default node executor / default node file copier, and use the copy file step on your workflow like this.
So, this is important: the WinRM plugin isn't in active development (and Rundeck 2.6 branch is out of support/maintenance), the best way to deal with this is to move to the latest Rundeck version and use the PyWinRM plugin (out of the box with Rundeck, on active development and easiest to configure compared by the old "Overthere" WinRM plugin) and use the copy step as the same way.

Minikube on Windows does nothing on start

I have followed all the instructions on Minikube carefully (I thought). I installed it on Windows 10 (ver 1.7.2), started a Powershell console under Administrator, set the 3 PROXY variables (I am behind a proxy), enabled the Microsoft-Hyper-V, and ran the cmd: minikube start --vm-driver=hyperv
It downloads the VM boot images, then I get the following line output:
* Creating hyperv VM (CPUs=2,....etc) ....
AND THAT'S IT!
Nothing else!! If I start the Hyper-V Manager I don't see any VMs there. The .minikube directory is populated with several dirs and files. But for the rest I am completely blind!
I have left it to run for half an hour or more. Still nothing.
I have tried terminating the process, stopping, deleting (in this case I get the output 'Deleting Kubenetes cluster' but whether this means anything I don't know) and flushing the .minikube directory ... then running it all again off a clean base. NADA! NOTHING! same thing!
Could someone please tell me what I am doing wrong? I thought this was supposed to work out of the box! Why don't I see my VM in Microsoft-Hyper-V manager for a start? I don't even get as far as seeing starting Kubenets cluster, yet I get no errors!
Try to follow this guide. It has a step by step instructions bout how to setup Docker and Minikube on windows 10 with Chocolatey.
Also here you will find an analogical issue with possible solutions.
Before you start again, remember to delete the .minikube folder after executing minikube delete to avoid any leftover configuration to persist.
Please let me know if that helped.
For the record, I flushed everything .. and tried several things from the above page, the K8 site and elsewhere. In a nutshell Docker for Desktop works and Minikube doesn't (not 100% anyway)! I was just curious back in February as to whether I could set up a local Kubenetes environment quickly and easily and I am afraid for me the answer is No: Minikube is not quick and easy. Also, you can enable Kubenetes on Docker Desktop now of course and it works out of the box as software should, so no more need for Minikube.
The following are the instructions for setting up and installing Minikube and its dependencies for use on Windows Pro or Enterprise with Docker Desktop and HyperV.
Install Kubectl
Create a new directory that you will move your kubectl binaries into. A good place would be C:\bin
Download the latest kubectl executable from the link on the Kubernetes doc page:
https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
Move this downloaded .exe file into the bin directory you created.
Use Windows search to type “env” then select “Edit the system environment variables”
In the System Properties dialog box, click “Environment Variables”.
In System Variables click on the “Path” Variable and then click “Edit”
Click “New” and then type C:\bin
Drag the newly created path so that it is higher in order than Docker's binaries. This is very important and will ensure that you will not have an out of date kubectl client.
Click "OK"
Restart your terminal and test by typing kubectl into it. You should get the basic commands and help menu printed back to your screen. If this doesn't work try restarting your machine.
Run kubectl version to verify that you are using the newest version and not the out of date v1.10 version.
Install Minikube
Download the Windows installer here:
https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe
Double click the .exe file that was downloaded and run the installer. All default selections are appropriate.
Open up your terminal and test the installation by typing minikube. You should get the basic commands and help menu printed back to your screen. If this doesn't work try restarting your machine.
Configure HyperV
In Windows Search type "HyperV" and select "HyperV Manager"
In the right sidebar click "Virtual Switch Manager"
Leave selected "New Virtual network Switch" and "External" and click "Create Virtual Switch"
Name the switch "Minikube Switch" (or whatever you would like to name it)
Click Apply and acknowledge the "Pending changes" dialog box by clicking "yes"
Once the switch has been created, click "Ok"
Starting Up Minikube
Since by default Minikube expects VirtualBox to be used, you need to tell it to use the hyperv driver instead, as well as the Virtual Switch created earlier.
Start up a terminal as an Administrator. Then, in your terminal run:
minikube start --vm-driver hyperv --hyperv-virtual-switch "Minikube Switch"
NOTE: all minikube commands must be run in the context of an elevated Administrator.

Patch Orchestration Application (POA) does not install updates in gMSA security cluster

I have standalone cluster 6.5.664.9590 on Windows Server 2019 with gMSA security.
Successfully deployed Patch Orchestration Application (POA) v1.4.1.
In GPO set "Notify to download updates".
POA successfully find and download updates, but does not install updates.
The Node Agent NTService does not creates repair tasks for installing updates on the nodes.
Get-ServiceFabricRepairTask empty.
Every ~3 minutes the following line logged in System log:
The Windows Modules Installer service entered the running state.
and after a few seconds, it shows:
The Windows Modules Installer service entered the stopped state.
Link on issue: https://github.com/microsoft/Service-Fabric-POA/issues/34
Add below section in your clustermanifest.
"ClientIdentities": [
{
"Identity": "NT AUTHORITY\SYSTEM",
"IsAdmin": true
}
]

Stopping Wildfly Windows Service failed

as mentioned from the title i have a problem stopping the wildfly windows service.
When i tried to stop the wildfly service via the server manager - services window the status of the wildfly service doens't change to stop from stop pending. But wildfly isn't running anymore (my web service is not reachable and also the server log says that wildfly was successfully stopped). to start the service again i have to restart the windows server.
i've tested this with different scenarios:
Windows Server 2008 R2 Datacenter + Wildfly 9
Windwos Server 2012 Datacenter + Wildfly 10
Windows 7 + Wildfly 10
I also tried to make changes in the service.bat like Chris French mentioned on https://developer.jboss.org/thread/238135?tstart=0 but there is no change.
Interessting is that the problem doens't exists on any of the scenarios when i added the service without adding any deployments to wildfly (so just the blank server). What means that i am able to start and stop the wildfly service successfully from the server manager services window when the wildfly server is "blank" and without any changes (for e.g. in standalone.xml).
So i think the problem must be my java ee project which contains a web service and a simple persistent project to access different my sql databases. In the standalone.xml i just added the mysql driver and the databases and i do some edits in the interface section (ip adress changes).
Any Ideas? Do i have to made changes in different config files (for e.g. the service.bat) when im deploying something to wildfly?
Sorry for my english and thanks a lot!
When installing the WildFly service, make sure you have the following parameters specified:
In WildFly 8: /user <username> /password <password>
in WildFly 10: /jbossuser <username> /jbosspass <password>
In the services.bat the documentation reads:
/user: username for the shutdown command
/password: password for the shutdown command
According to my experience, without these parameters, WildFly will move to status "stopping", but will not stop.
That works for me:
1. Always run the CMD as admin first.
2. If your JBOSS_HOME environment is not set, get sure that you navigate to WildFly home directory before you execute the script.
For example: cd "C:\Program Files\wildfly
It's matter, because the service.bat takes your current dir (%CD%) as JBOSS_HOME, if it's not set.
3. You’ve to install the service with a special parameter. /controller
It’s important that you tell wildfly service on which port your wildfly admin console is running.
Take a look in standalone.xml, search for “management-http”, get sure that you use the same port in parameter.
Example: (Default port is 9990)
./bin/service/service.bat install /controller localhost:9990
Done. Now start the service and wait until you can reach the wildfly console page.
After try to stop or restart the service in service.msc or with service.bat (service.bat start/stop/restart).
I had similar issue but it turned out I needed a JAVA_HOME in standalone.conf.bat under bin folder. Simply uncomment the line that sets the JAVA_HOME variable and update its value with the desired path.
set "JAVA_HOME=C:\Program Files\Java\jdk1.8.0_121"
Above solution worked for me.
I had the "stopping" problem, when JAVA_HOME was set directly in jboss_cli.bat, pointing to the older jdk version previously installed on my machine. Check jboss_cli.bat for correct path of JAVA_HOME or simply use the JAVA_HOME environment variable (you might have to delete set JAVA_HOME line in jboss_cli.bat).

Jenkins windows slave service does not interact with desktop

I have followed this guide to install a jenkins slave on windows 8 as a service:
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service#InstallingJenkinsasaWindowsservice-InstallSlaveasaWindowsservice%28require.NET2.0framework%29
I need to run a job that interact with the desktop (run an application that opens a browser etc.). So after I have installed the slave as a service (running jnlp downloaded from the master) I have changed the service "Log on" to "Allow to interact with display".
For some reason its only possible to enable this for the "Local System account" even though its recommended to run the service as a specified user, eg. jenkins.
But nothing happens when I execute the job, the browser is not opened. If I instead stop the service and just launch the slave through the jnlp file the job runs fine - the browser is opened.
Anybody had any luck interacting with the desktop when running a jenkins windows slave as a service?
Services run since Vista in Session 0 and the first user is now in Session 1. So you can't interact any longer. This is called Session 0 Isolation.
Microsoft explains this here and here. You have to use 2nd Program which uses IPC to communicate to the Service.
I had lots of issues running Jenkins in Windows using the service.
Instead I now disable the service and run it from CMD.
So open CMD.
cd C:\Program Files (x86)\Jenkins
java -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar
jenkins.war --httpPort=9091
To resolve it, first create Windows auto-logon as I explain here:
https://serverfault.com/questions/269832/windows-server-2008-automatic-user-logon-on-power-on/606130#606130
Then create a startup batch for Jenkins agent (place it in Jenkins directory). This will launch agent console on desktop, and should allow Jenkins to interact with Windows GUI:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be download from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
EDIT :
If you're getting black screenshots (when using Selenium or Sikuli, for example), create a batch file that disconnects Remote Desktop, instead of closing the RDP session with the regular X button:
%windir%\system32\tscon.exe %SESSIONNAME% /dest:console
Consider running the Java slave server directly at startup and then using something to monitor and restart should the server go down (e.g., Kiwi Restarter).
Please check the services (# TestNode) make sure the "Interactive Services Detection" service is STARTED, by default the startup type is set to Manual, you may like to set it to automatic as well.
After service started, when you run your test in the Test Node, you will see something like the below:
Click on it and choose view the message
You will see the activities happen there. Hope this helps :D
Note: If login with other account and cannot view the Interative Services Detection prompt, restart the service again.
My Jenkins Service runs as user "jenkins" and all I did was to create Desktop folders in: C:\Windows\system32\config\systemprofile\desktop and if 64 bit Windows also in C:\Windows\SysWOW64\config\systemprofile\desktop - then it runs perfectly.
Make sure that Desktop folders are created as such:
%WINDOWS%/System32/config/systemprofile/Desktop
%WINDOWS%/SystemWOW64/config/systemprofile/Desktop
Presence of those can sometimes be mandatory while running some Java software as a Service.