sonatype / chef-nexus-repository-manager Goto Github PK

Possible to get into proper Chef versioning for metadata.rb?

To be very honest, I'm not 100% sure this is the correct place to race this issue, but as far as I understood the cloudformation templates provided at [1] , they use this chef recipes to install nexus on a ec2 instance.

The issue is quite simple:

1. install nexus via cloudformation template (described at [1])
2. check nexus is correctly up and running
3. stop the EC2 instance running nexus
4. start the EC2 instance you just stopped
5. check if nexus comes up again -> no, nexus is not coming online again

I would expect nexus to come up and running with no data lost again. I did experience a similar issue before with an other tool (jenkins) the simple solution was to start docker with --restart=always.

[1] https://help.sonatype.com/integrations/cloud-deployments/cloudformation---repository-manager

nexus.vmoptions is bundled in the tar, so editing it after the fact is cumbersome ... would be nice to to have the configure.rb recipe take in overrides for the file .. or even just straight up file rather than template.

My NXRM install is failing. Look like same problem seen in adamsb6/s3_file#114. If so a tertiary dependency is breaking the cookbook recipe? The parsing of S3 license crashes using the 's3_file' package dependency which itself uses a 'rest-client' dependency which is poorly maintained and uses very old version.

I got here using the latest Guide minimal template. Works fine when no parameters are supplied but fails if I provide s3 license file options...
https://s3.amazonaws.com/sonatype-cloudformation-templates/nexus-repository-manager/1.0.20190212-170522.3f01289/minimal-single-instance.template

Looking at https://help.sonatype.com/display/NXRM3/Run+as+a+Service#RunasaService-systemd and prescribed Type=forking, whereas cookbook is Type=simple ... curious if reason for that?
https://github.com/sonatype/chef-nexus-repository-manager/blob/master/recipes/systemd.rb#L13

I am currently running 3.7.1 and am getting a file descriptor error when logging into the UI as admin. I found the following ticket; NEXUS-14857 that reference the same issue and took a look at the config file that is referenced. The following lines are present in the limits.conf file which sould resolve the problem, but I am still getting the warning

nexus hard nofile 65536
nexus soft nofile 65536

Currently we have to publicly expose the app, manually log in and change the password, which seems pretty unacceptable from a security perspective.

The workaround would be to deploy with basic auth on the ingress, and then log in to the UI and change the password that way, before disabling basic auth on ingress, but this hurts the simplicity and reproducibility of the deployment process. It would be much better if the default credentials were set by a secret, optionally generated by the chart or passed in externally.

using release-0.5.20180105-135811.666c150.

And running nexus3 install via Docker file: https://github.com/sonatype/docker-nexus3/blob/master/Dockerfile

Receives the following error:
Recipe: java::set_java_home

• directory[/etc/profile.d] action create (up to date)
• template[/etc/profile.d/jdk.sh] action create
  • create new file /etc/profile.d/jdk.sh
  • update content in file /etc/profile.d/jdk.sh from none to b2915a
    --- /etc/profile.d/jdk.sh 2018-01-17 14:50:30.584455369 +0000
    +++ /etc/profile.d/.chef-jdk20180117-79-1t39dff.sh 2018-01-17 14:50:30.584455369 +0000
    @@ -1 +1,2 @@
    +export JAVA_HOME=/opt/java
  • change mode from '' to '0755'
    Recipe: java::oracle
• yum_package[tar] action install (up to date)
• java_ark[jdk] action install
  • yum_package[curl for download_direct_from_oracle] action install (up to date)
  • download oracle tarball straight from the server[2018-01-17T14:50:37+00:00] FATAL: Failed to extract file server-jre-8u152-linux-x64.tar.gz!

Running handlers:
[2018-01-17T14:50:37+00:00] ERROR: Running exception handlers
Running handlers complete
[2018-01-17T14:50:37+00:00] ERROR: Exception handlers complete
Chef Client failed. 2 resources updated in 09 seconds
[2018-01-17T14:50:37+00:00] FATAL: Stacktrace dumped to /etc/chef/local-mode-cache/cache/chef-stacktrace.out
[2018-01-17T14:50:37+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2018-01-17T14:50:37+00:00] ERROR: exit
[2018-01-17T14:50:37+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
ERROR: Service 'mynexus3' failed to build: The command '/bin/sh -c curl -L https://www.getchef.com/chef/install.sh | bash && /opt/chef/embedded/bin/erb /var/chef/solo.json.erb > /var/chef/solo.json && chef-solo --recipe-url ${NEXUS_REPOSITORY_MANAGER_COOKBOOK_URL} --json-attributes /var/chef/solo.json && rpm -qa chef | xargs rpm -e && rpm --rebuilddb && rm -rf /etc/chef && rm -rf /opt/chefdk && rm -rf /var/cache/yum && rm -rf /var/chef' returned a non-zero code: 1

Hi,

we have a corporate proxy, so I provided the nexus package in our local Artifactory and adjusted the variable NEXUS_DOWNLOAD_URL. The download url is over https using a self signed corporate ssl certifacte. Internally the tar_extract is not able to either fetch the certificate from the local system nor to ignore the ssl certificate issue (skip ssl verify).

Therefore I used curl to download the nexus artifact and tried to feed it locally to tar_extract.

A solution can be to adjust tar_extract in download.rb file as following:

tar_extract node['nexus_repository_manager']['nexus_download_url'] do
  action :extract_local
  target_dir node['nexus_repository_manager']['nexus_home']['path']
  checksum node['nexus_repository_manager']['nexus_download_sha256']
  creates node['nexus_repository_manager']['nexus_home']['path'] + '/bin'
  tar_flags [ '-P', '--strip-components 1' ]
end

Adding action :extract_local hard coded is not optimal I know, but maybe there is a solution to pass the configuration via an environment variable as the other options.

The Sous Chefs released a version '2.y.z' of the java cookbook.
Please upgrade the dependencies of this cookbook to allow usages for those versions.

See Changelog of Sous Chefs Java Cookbook

When initially setting up a Chef+Nexus instance, this repo was not found in Supermarket : https://supermarket.chef.io/cookbooks/nexus
Is there a timeline for getting it into the Supermarket?

I failed to start nexus3 by sonatype/nexus3:3.14.0 docker image due to some permission problems regarding etc folder of data directory. It seems that 'etc' directory created inside data directory of nexus (which is created with chef recipe) has owner of root, so as nexus process has UID of 200 by default, it fails to write on this directory and following error occurs while starting nexus server:

1) Error injecting constructor, java.lang.RuntimeException: java.nio.file.AccessDeniedException: /nexus-data/etc/logback
  at org.sonatype.nexus.internal.log.LogbackLoggerOverrides.(LogbackLoggerOverrides.java:64)
  at / (via modules: org.sonatype.nexus.extender.modules.NexusBundleModule -> org.eclipse.sisu.space.SpaceModule)
  while locating org.sonatype.nexus.internal.log.LogbackLoggerOverrides
  while locating java.lang.Object annotated with *
  at org.eclipse.sisu.wire.LocatorWiring
  while locating org.sonatype.nexus.internal.log.LoggerOverrides
    for the 3rd parameter of org.sonatype.nexus.internal.log.LogbackLogManager.(LogbackLogManager.java:84)
  at / (via modules: org.sonatype.nexus.extender.modules.NexusBundleModule -> org.eclipse.sisu.space.SpaceModule)
  while locating org.sonatype.nexus.internal.log.LogbackLogManager
  while locating java.lang.Object annotated with *

I tried to run nexus docker with following command:

run -p 18081:8081 -p 15000:5000 -p 18443:8443 --name nexus_tmp -v $BASE_DATA_DIR/etc/ssl:/opt/sonatype/nexus/etc/ssl -v $BASE_DATA_DIR/data:/nexus-data -v $BASE_DATA_DIR/etc/jetty/jetty-https.xml:/opt/sonatype/nexus/etc/jetty/jetty-https.xml -v $BASE_DATA_DIR/etc/nexus.properties:/opt/sonatype/sonatype-work/nexus3/etc/nexus.properties sonatype/nexus3:3.14.0

Here is the complete log:
nexus.log

Hi the context of Openshift and secure SCC, the entrypoint is not correct:

When the entrypoint will be call, the value of USER_NAME will be empty.

sed "s@${USER_NAME}:x:\${USER_ID}:@${USER_NAME}:x:${USER_ID}:@g" /etc/passwd.template

I think the best way of settings this is by using the suggestion in the Openshift Doc:

Change in the Dockerfile

# All permission must be corrected in the Image too
RUN chmod g=u /etc/passwd 
ENTRYPOINT [ "uid_entrypoint" ]
USER 1001

Change in entrypoint

if ! whoami &> /dev/null; then
  if [ -w /etc/passwd ]; then
    echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
  fi
fi

I understand correctly?

Thanks!