We Keep Coding

Launching Windows Jenkins Agents without JNLP

Built a new Windows Server 2016 to act as a target for jenkins orchestrated builds. We are not supposed to use oracle java anymore, so I got coretta openJDK. OpenJDK does not support javaws any more. The executable does not ship with it. I have seen some scripted workarounds, but they do not work and are poorly written to boot.
What are we supposed to use to launch slave agents on Windows machines?

There are several ways to implement this but since this is a windows server you can follow steps on https://github.com/kohsuke/winsw/blob/master/doc/installation.md#winsw-installation-guide to install jenkins slave as service without javaws.

I believe #Mike was referring to: Install Slave as a Windows service (cmd version), which does not need JNLP/javaws.
OR, under Jenkins 2 (we are using 2.121.1 plus WMI Windows Agents (aka windows-slaves:1.4), there is now an option to "Let Jenkins control this Windows slave as a Windows service", essentially in the same fashion as a Linux node.
You must have an Admin account (and password). We had to follow the guidance to edit registry when "Windows agents fail to start via DCOM" (Guidance is for Server 2012) to remotely manage the service. So far, seems to be working OK, YMMV. So far, seems to be working OK, no "subtle probelms"; YMMV.
For entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID{72C24DD5-D70A-438B-8A42-98424B88AFB8}
HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}
(There are several matches for the keys; just change the two locations indicated)
Launch 'regedit' (as Administrator)
Find (Ctrl+F) the following registry key: "{72C24DD5-D70A-438B-8A42-98424B88AFB8}" in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\
Right click and select 'Permissions'
Change owner to administrators group (Advanced...).
Change permissions for administrators group. Grant Full Control.
Change owner back to TrustedInstaller (user is "NT Service\TrustedInstaller" on local machine)
Repeat the steps 1-6 for HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}
Restart Remote Registry Service (Administrative Tools / Services)

For me the easiest and best working solution to launch Windows Jenkins Agents without JNLP was to run in the command prompt java -jar agent.jar ... command. The command parameters should be grabbed from the url of the agent:
http://your_jenkins_url/computer/your_agent_name_or_ip/
I downloaded the agent.jar on my PC, moved it to a desired directory, launched the Command Prompt from the dir where the agent.jar was moved and executed the proposed command with the appropriate parameters.
In my case:
java -jar agent.jar -jnlpUrl http://your_jenkins_url/computer/your_agent_name_or_ip/slave-agent.jnlp -secret 76986574e97c2b635c7076740dc93326eaaf5a3ad30573144915489a1ccfee44 -workDir "D:\jenkins"
This was one of the proposed approaches in the docs here - https://www.jenkins.io/doc/administration/requirements/upgrade-java-guidelines/
Java Web Start Java Web Start has been removed in Java 11. When a
Jenkins controller is running on Java 11, the Java Web Start button
will no longer appear in the Web UI. Agents for a Java 11 Jenkins
server can’t be launched from a *.jnlp file downloaded to a web
browser.
There are no plans to replace this functionality. Connect agents to
Jenkins on Java 11 with plugins like SSH Build Agents Plugin, with
operating system command line calls to java -jar agent.jar, or by
using containers.

JDK 7 Update 80 installation issue "A semi-colon found in selected path"

I'm trying to install JDK 7 on a Windows 7 machine and constantly getting the error "A semi-colon found in selected path" no matter what path I select for the installation.
Tried with different updates of JDK and it didn't help either.
EDIT: Installation log shows the following error:
Thu May 05 06:34:19 2016
:: JDK installation failed. Return Code: 1603, ErrorCode: 0

This error message is displayed by the Microsoft Windows Installer engine and is a general error code that indicates a problem occurred during the installation.
Read on to learn how to sidestep this speed bump.
The following is a non-exhaustive list of known causes for this error:
Short file name creation is disabled on the target machine.
An Install Script custom action is prototyped incorrectly.
A file is locked and cannot be overwritten.
The Microsoft Windows Installer Service is not installed correctly.
The Windows Temp folders are full.
The setup was corrupted after installation and, therefore, fails with this error during un-installation.
An older version of Install Shield Developer is being used.
A general error occurred during the installation.
Print and File sharing is not installed or enabled when installing MSDE 2000.
How to Avoid this Error
The following solutions have resolved this error in the majority of cases:
Make sure short file name creation is enabled on the target machine. You can check to ensure that the target machine does not have short file name creation disabled by navigating to the following registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Make sure the value "NtfsDisable8dot3NameCreation" is equal to 0. This indicates that short file name creation is enabled. A value of 1 indicates that this functionality is disabled. You should change the value to 0.
After modifying this value, the target machine should be rebooted before attempting to launch the setup again.
Note: If the target machine should normally have short file name creation disabled, it can be disabled after the install completes by resetting "NtfsDisable8dot3NameCreation" to 1 and rebooting.
To ensure that the Windows Installer Service is properly installed and configured, it is recommended that users install the file InstmsiA.exe on Windows 95/98/Me or InstmsiW.exe on Win NT systems. These files are shipped with your InstallShield product and are located in the following location:
<Product Path>\Redist\Language Independent\i386
Empty all temporary folders. The specific temporary folders for a machine can be determined by accessing the DOS prompt and typing set. Note the values listed for TEMP and TMP, and delete all files in those locations.
Make sure no other applications, including utilities such as virus scanners, are running in the background. Close all running applications and utilities, and launch the installation again.
If this error occurs during un-installation, use the Microsoft Windows Installer CleanUp utility to uninstall the installation.
Once the installation has been successfully un-installed, you can then debug the project to determine what caused the original error.

Put your installer executable to C:\ and run it from there.
More info here: http://wills-tech-notes.blogspot.com/2015/12/cannot-install-java-semicolon-found-in.html

The Error which you are getting is normally it throws during java update installation, Not, the first time installation.
Please kindly follow the below steps to resolve your issues. Let's give a try.
Step 1:
Just want to ensure if you have already java installed on your machine partially.
Follow the below entries in command prompt:
java -version - If it throws error we are good.
echo %JAVA_HOME% and echo %JRE_HOME%
echo %PATH% - If you see the Java entries you may need to clear all this.
echo %CLASSPATH% - Here as well as said in above.
If no results from the Step 1, Please follow Step 2.
Step 2:
Check your C: drive for to verify there should not any Java installation folders. If yes, Please delete those.
Clear all your logs from your machine(If it contains any existing java related logs)
https://www.java.com/en/download/help/plugin_cache.xml
Step 3:
Actually, we do not require to install the Java, instead we can download the Zipped java file and locate into dedicated drive.
And then, make all your environment variables entries into this location. In, this case you are good i believe.
If you still face issues, do let me know?

Try this and maybe you'll get your job done
1 Close the installer when you see Java error 1603. (It has installed a
bunch of files, but exits prematurely.)
2 Open javacpl.exe from C:\Program Files (x86)\Java\jre1.8.0_XX\bin (or
for x64, C:\Program Files\Java\jre1.8.0_XX\bin) where XX is the update
number.
3 Uncheck "Enable Java content in the browser" on security tab and click
OK to close Java control panel
4 Retry installing Java. It usually succeeds for this time.
5 Open javacpl.exe again (see step #2)
6 Check Enable Java content in browser on security tab and click OK to
close Java control panel
7 If it still fails, try uninstalling windows update KB2918614, then
reboot and try these steps again.

Try following steps:
Run installer from c:/
Run jdk*...*.exe /log msi.log to see installation logs, please attach
them if it won't help you understand a cause of the problem
In the related JDK bug an issue with an environment was a cause of the problem.

uninstall KB3139923 helped in my case

I had the same problem with version 8 and the solution was to run the installer as Administrator (right click, then "Run as Administrator").

Error starting Wildfly 10.0.0.Final

I haven't been able to find a specific answer to what could be causing this issue though I am hoping it is something quite simple.
Issue.
I have installed version 10.0.0.Final from the Wildfly website and extracted into C:\Program Files\wildfly-10.0.0.Final.
I then navigate to C:\Program Files\wildfly-10.0.0.Final\bin directory via windows command prompt and execute the standalone.bat command.
Wildfly doesn't start and I get the following exception:
java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
If anyone has encountered this error message before, then your guidance would be greatly appreciated.
Thanks!
Ben

The error appears to be a result of either file permissions on the JBoss home directory, lack of space available, or a missing directory.
Relevant posts include:
Starting WildFly 8.2 under a user with limited permissions
Which suggests setting the JBOSS_BASE_DIR property to the root folder of the JBoss installation.
https://github.com/jboss-dockerfiles/wildfly/issues/24
Suggests this can occur if the root folder does not have enough space allocated for the user (typically running in Unix environments).
Error in starting Wildfly 8.0 server with JDK 1.8
The logs/boot.log didn't exist. The author manually created the file which then revealed a permission issue on the log file (more likely on the entire Jboss installation folder).

The issue was caused due to the command prompt. As I am using windows 10, I needed to be using Command Prompt (Admin),rather than just the normal cmd hence the permission issues alluded to previously by pczeus.
After using Command Prompt (Admin), I was able to start the server.

Using Java to find Postgresql installation location

I want to find out the installation location of Postgresql and need to make some changes in postgresql.conf and pg_hba.conf files and restart Postgresql.
Is there any way to identify the installation directory which can be applied to Windows/Unix/Linux ? Any help or suggestion will be really appreciated.

Ask PostgreSQL:
SHOW config_file;
SHOW hba_file;
or:
SELECT current_setting('config_file');
SELECT current_setting('hba_file');
This, of course, requires PostgreSQL to be running, listening on TCP/IP, and on the default port. It also requires you to be able to authenticate. You would need to prompt the user for the port (default to 5432) and credentials.
There is no generic way to determine the PostgreSQL data directory location without asking a running PostgreSQL instance, because:
There might be more than one running PostgreSQL instance
PostgreSQL on Mac OS X might've been installed via Homebrew (Mac OS X), Postgres.app (Mac OS X), system package management (Linux), ports (BSD), the EnterpriseDB installer, various 3rd party rollup distributions, the .zip binaries, or from source.
PostgreSQL might be started and run from launchd (Mac OS X), as a Windows service (Windows), from systemd/upstart/init (Linux/BSD), manually by the user with pg_ctl, etc. A data directory can be specified on the startup command line.
So the whole idea that you can figure out "the" location of the PostgreSQL datadir is bogus.
If you're writing software that relies on PostgreSQL, consider bundling your own copy with the .zip binaries, starting it with pg_ctl and running it on a non-default port so it doesn't interfere with any PostgreSQL install the user may've put on their system themselves.

You can define custom environment variable like POSTGRES_HOME and use it similar to JAVA_HOME
POSTGRES_HOME = /usr/local/pgsql
pg_hba.conf path = POSTGRES_HOME/data/pg_hba.conf

"No files available for download"

There is a strange problem with Netbeans. I'm trying to create new project with remote resources but when I enter all FTP and project information, Netbeans says
No files available for download. Try to check Passive mode in the
remote configuration
Although I tried the passive mode, it isn't the problem. There are many folders and files and I can see them via FTP client or I can create the project with same method on another Netbeans which is running another computer.
Both of them has Netbeans 7.0, both of them running Windows 7 and both of them using same internet connection!
There are no firewall or similar protection by the way.

For Netbeans 7.3, with Windows 7, using JDK 7
Open CMD as Administrator and run the following:
netsh advfirewall set global StatefulFTP disable
To open CMD as Administrator in Windows 7:
Select Start
In the "Search programs and files" box
Enter "CMD"
Find the result above and right click on it
Select "Run as Administrator" from the context menu
I found this after some digging via Mansiemans shared link. Some of the commands on that thread, did not work, so I am sharing the one that did work.

Initial Directory: "/"
Port: "21"
Set Passive mode on

You don't need to uninstall Java or re-install NetBeans. Just change the Java version used by Netbeans.
Edit file: <netbeans dir>\etc\netbeans.conf
Change this line: netbeans_jdkhome="C:\Program Files\Java\jre6"

I did not uninstall any thing.
I got jdk 1.6 folder from another computer and copied it to my computer in java installation directory.
Then I edited the \etc\netbeans.conf.
Changed this line: netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0"
jre6 was not working.
I did this in passive mode.

Uninstall java 7 and java se 7 development and install the last java 6 version http://www.java.com/en/download/inc/windows_new_xpi.jsp

upload directory in connector was automatically named as the project, making the dir on server that the connector will test: ftp://mysite.foo/mysite/mysite instead of ftp://mysite.foo/mysite/
clearing "upload directory" field worked for me

This page has a suggestion that worked for me. Apparently, Windows 7 / Vista firewall blocks certain FTP operations. When I turn off my Vista firewall, Netbeans does its thing.

If passive mode fails to get files then connect by Turning off your Firewall. In my case it worked. Then you can create a Rule in Firewall to allow netbeans.

This could be because your user account on the FTP server is configured to change to an initial directory upon connection.
Example: The Netbeans path is showing ftp://example.com/www/example.com (combining your provided host, initial directory and upload directory settings). However, your FTP user account is configured to initially connect to /www as the FTP root. Despite what Netbeans is telling you, you are actually connecting to ftp://example.com/www/www/example.com because, upon connection, the FTP server has changed the directory to www for your user account.
In which case, even though Netbeans is showing the correct path in the project wizard and in the console, you may not actually be connecting to the path in your Netbeans settings.
You can usually check if this is the case easily if you have a hosting account control panel with an FTP settings page. Your host may, however, not allow you to change the FTP root for security reasons (or perhaps you just shouldn't).
If you cannot change the FTP user root, or would prefer not to, then (in the e.g. above) you will have to make sure the Netbeans FTP path is ftp://example.com/example.com missing out the "www" directory (even though that is actually part of the correct path) because the FTP server will automatically change to this as the FTP root.
The above approach fixed this problem for me.

Set the initial directory chmod to 777.