I'm trying to create a new SSH container to an existing fabric and It was successfully created using this command:
fabric:container-create-ssh --proxy-uri http://"root-container":8181/maven/download/ --jvm-opts "-Xms1024m -XX:MaxPermSize=1024m -Xmx2014m -Djavax.net.debug=ssl" --path /app/testing/ --host "testIP" --private-key ~/.ssh/id_rsa --profile default --profile anotherprofile --resolver localhostname --zookeeper-password "zookeepr pass" testing-container
The problem is that once i created this new container all the existing ssh container changes their maven download/upload proxy to the above container IP
so instead of using http://"currentroot":8181/maven/download/ to http://testIP:8181/maven/download/
i tried a lot to change the maven proxy from the "root-container" fabric profile and default profile but still couldn't reach a solution?
Is there a missing step that i should take to solve this issue in adding a new ssh container without updating the existing maven repo?
It depends on what is anotherprofile
http://host:port/maven/download/ URIs are registered in Zookeeper registry that's used by fabric environment.
fabric-maven-proxy feature, which is declared in fabric profile is the feature that's responsible for starting a maven proxy inside any container that has this feature/profile installed. Please check if your new container has this feature installed. Maybe anotherprofile has fabric profile set as parent?
How containers use remote repositories
Each container, when provisioned by fabric-agent, uses io.fabric8.agent PID configuration (OSGi configuration admin) and the property is org.ops4j.pax.url.mvn.repositories. It contains a list of remote repositories that are searched for artifacts to install in container.
But there's some dynamism involved too. Fabric agent always searches Zookeeper registry and finds URIs that are registered by other containers that run the above mentioned feature (fabric-maven-proxy). All such discovered URIs are prepended to the list found in org.ops4j.pax.url.mvn.repositories property.
How to check maven problem in logs
If you add karaf profile to a container, you'll have logging configuration available in org.ops4j.pax.logging PID - you can nicely configure it in hawtio. By default, there's commented section like this:
# help with identification of maven-related problems with fabric-maven
#log4j.logger.org.eclipse.aether = TRACE
#log4j.logger.org.apache.http.headers = DEBUG
#log4j.logger.io.fabric8.maven.util = TRACE
#log4j.logger.io.fabric8.maven.url = TRACE
#log4j.logger.io.fabric8.agent.download = DEBUG
You can uncomment these to see (much) more information about how maven repositories are used.
Related
I am trying to run JBeret Batch on a Wildfly Domain Cluster locally, but I keep getting the error
"WFLYCTL0030: No resource definition is registered for address [ (\"deployment\" => \"ExampleJob.war\"), (\"subsystem\" => \"batch-jberet\") ]"
To host the cluster I tried to use the default configuration. I am using Wildfly 26.1.3 .
To run my setup I am using this commands on my windows machine to run the Master and Slave.
.\bin\domain.bat --host-config=host-master.xml -Djboss.domain.base.dir=domain1
and
.\bin\domain.bat --host-config=host-slave.xml -Djboss.domain.base.dir=host1 -Djboss.domain.master.address=127.0.0.1 -Djboss.management.http.port=9991
After That I deploy any batch application and try to run it in the adminpanel and get the error.
I tried also to use the cli, which didnt change anything.
I also tried to run it without the base.dir config so it uses the same folder but that did not change something.
I also tried to run different JDKs (I am now using JDK11).
To test that it is not working I tried this job from jberet directly. Also I tried other example Jobs like csv2json and keep getting the same error.
In Standalone the example jobs work.
We installed fuse-online 7.4 on openshift 3.11. We created an integration containing an OpenApiProvider connection and an SQL connection.
When we publish the integration, the build fails with the following error:
"repo1.maven.org: Name or service not known: Unknown host repo1.maven.org: Name or service not known"
Openshift is installed behing an enterprise http proxy
The image registry.access.redhat.com/fuse7/fuse-ignite-s2i is pulled correctly since docker is configured with proxy.
syndesis-server DeploymentConfig has been set with proxies environment variables
I suppose that, since the buildconfig for the integration is created dynamically, is not possible to inject HTTP_PROXY,HTTPS_PROXY,NO_PROXY env variables to the build pod.
We read https://docs.openshift.com/container-platform/3.11/install_config/http_proxies.html#s2i-builds but since we don't have any rights to modify s2i image we cannot proceed.
Is there any way to provide proxy information during during fuse-online integration build?
Finally we succeeded to inject http proxy environment variables in dynamic created build pods.
We modified syndesis-server-config config map reporting proxy variables on mavenOptions key like this:
mavenOptions: "-XX:+UseG1GC -XX:+UseStringDeduplication -Xmx310m -Dhttp.proxyHost= -Dhttp.proxyPort= -Dhttps.proxyHost= -Dhttps.proxyPort= -Dhttp.nonProxyHosts="
Thanks for the support
Let me know if you have any other idea of resolving the issue
Can you check the DNS of your network connection? Not sure why but sometimes I have to use one of the "reliable" DNS on my machine (like the 8.8.8.8 from Google) to make sure repo1.maven.org is reachable.
You can check if this is the problem trying a simple
$ ping repo1.maven.org
If that doesn't work, you have to check your DNS.
Every time I try logging in to https://cd.screwdriver.cd/login I am getting {"statusCode":403,"error":"Forbidden","message":"User github:tannupriyasingh is not allowed access"} error.
I tried adding webhook to Github with steps mentioned here https://developer.github.com/webhooks/creating/ and running into Tunnel 541e163b.ngrok.io not found response
I am expecting to login and create a deployment pipeline in screwdriver-cd.
https://cd.screwdriver.cd is our demo Screwdriver cluster used for deploying open source Screwdriver. We currently do not host any instances for public use. You can login with Guest Access to look at the UI in cd.screwdriver.cd, but you'll need to run your own instance of Screwdriver in order to create a deployment pipeline.
A couple options for running your own instance:
Helm chart: https://docs.screwdriver.cd/cluster-management/helm
Docker compose: https://docs.screwdriver.cd/cluster-management/running-locally
I am trying to start a google compute engine (GCE) instance with a pre-configured FQDN. We are intending to run an application that is licensed based on the contents of /etc/hosts.
I am starting the instances using the Google Cloud SDK utility - gcloud.
I have tried setting the "hostname" key using the metadata option like so:
gcloud compute instances create mynode (standard opts) --metadata hostname=mynode.example.com
Whenever I log into the developer console, under computer, instances, I can see hostname under "Custom metadata". This appears to be a new, custome key - it has no impact on what:
http://metadata.google.internal/computeMetadata/v1/instance/hostname
returns.
I have also tried setting "instance/hostname" like the below, which causes a parsing error when using gcloud.
--metadata instance/hostname=mynode.example.com
I have successfully used the startup scripts functionality of the metadata server to run a startup script that parses the new, internal IP address of the newly created instance, updated /etc/hosts. This appears to work but doesn't feel "like the google way".
Can I configure the FQDN (specifically, a domain name, as the instance name is always the hostname) of an instance, during instance creation, using the metaserver functionality?
try this:
Go to your GCE >> VM instances panel.
stop your gce instance.
clic on the instance name.
Edit your instance, adding this values on Custom metadata fields:
Key field: hostname / Value field: your.server.hostname
Key field: startup-script / Value field: sudo -s hostnamectl set-hostname your.server.hostname
setup-example-image.png
Finally, start your instance and test with a hostnamectl command.
regards!
According to this article 'hostname' is part of the default metadata entries that provide information about your instance and it is NOT possible to manually edit any of the default metadata pairs. You can also take a look at this video from the Google Team. Within the first few minutes it is mentioned that you cannot modify default metadata pairs. As such, it does not seem like you can specify the hostname upon instance creation other than through the use of a start-up script like you've done already. It is also worth mentioning that the hostname you've specified will get deleted and auto-synced by the metadata server upon reboot unless you're using a start-up script or something that would modify it every time.
If what you're currently doing works for what you're trying to accomplish, it might be the only workaround to your scenario.
Here is a patch for /usr/share/google/set-hostname to set FQDN to GCE instance.
https://gist.github.com/yuki-takeichi/3080521322f0f1d159ea6a343e2323e6
Before you use this patch, you must set your desired FQDN in your instance's metadata by specifying hostname key.
Hostname is set each time instance's IP address is renewed by dhclient. set-hostname is just a hook script which dhclient executes and serves new IP address and internal hostame to, and modifies /etc/hosts. This patch changes the source of hostname by querying instance's metadata from metadata server.
The original set-hostname script is here:
https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google_config/bin/set_hostname.
Use this patch at your own risk.
When creating a VM, you can specify a custom FQDN hostname as an optional parameter. This feature is currently in Beta.
$ gcloud beta compute instances create INSTANCE_NAME --hostname example.hostname
This should work across OSes, and eliminate the need for workaround scripts.
More info in the docs.
-- Sirui (Product Manager, Google Compute Engine)
I've looked throughout this site to find answered questions and found a few things that work but with a couple solutions combined. This thread seems the place to answer.
1) echo example.com > /etc/hostname
2) add -- 127.0.1.1 example.com in /etc/hosts
3) add -- hostnamectl set-hostname
example.com -- command to /etc/rc.local script
4) uncomment /etc/dhcp/dhclient.conf line:
supersede domain-name "example.com";
5) profit.... Seems to stick after each reboot
(Note example.com is your domain name: fqdndomain.com - yourfqdndomain.org)
Also note this is for Ubuntu or Debian. Other Unix May slightly vary. I've tested this on Ubuntu 16.04
Always on the wording NOT possible to manually edit any of the default metadata pairs, how about the instant level default metadata "/scheduling"? we could set them manually as mentioned in this article
Are there any simple ways to see what wars have been deployed in Jboss AS and undeploy some of them? I want to do this from the command line.
I tried using jmx but I keep getting exception saying "org.jboss.util.NestedRuntimeException: jmx not bound;" I'd prefer to do it in a way where I don't have to stop and start the application server.
You can approach this in three ways in JBoss Application Server 7:
Management Console
Management CLI
Deployment folder
Management Console
Being a GUI, the Management Console is the most visual of the three, and you can see the list of deployed applications under the Deployment window. You have the option to Disable and Remove the deployed applications listed here. This screenshot is from AS7.0.2, and some windows have and will change with the addition of tabs, but the general functionality remains the same.
Management CLI
The Management Command Line Interface is a new addition to AS7. The CLI exposes a lot of low-level functionality, and is a powerful tool once you get familiar with the commands and operations. As you might expect, you can run help to show the commands, or run <commandname> --help for more information on a specific command. Two useful commands are deploy and undeploy, so let's look at their help information. I'll give Linux examples, but you can insert your flavour of OS as required.
Here's deploy:
[standalone#localhost:9999 /] deploy --help
SYNOPSIS
deploy (file_path [--name=deployment_name] [--runtime_name=deployment_runtime_name] [--force] | --name=deployment_name) [--server-groups=group_name (,group_name)* | --all-server-groups]
DESCRIPTION
Deploys the application designated by the file_path or enables an already existing
but disabled in the repository deployment designated by the name argument.
If executed w/o arguments, will list all the existing deployments.
ARGUMENTS
file_path - the path to the application to deploy. Required in case the deployment
doesn't exist in the repository.
The path can be either absolute or relative to the current directory.
--name - the unique name of the deployment. If the file path argument is specified
the name argument is optional with the file name been the default value.
If the file path argument isn't specified then the command is supposed to
enable an already existing but disabled deployment, and in this case the
name argument is required.
--runtime_name - optional, the runtime name for the deployment.
--force - if the deployment with the specified name already exists, by default,
deploy will be aborted and the corresponding message will printed.
Switch --force (or -f) will force the replacement of the existing deployment
with the one specified in the command arguments.
--server-groups - comma separated list of server group names the deploy command should apply to.
Either server-groups or all-server-groups is required in the domain mode.
This argument is not applicable in the standalone mode.
--all-server-groups - indicates that deploy should apply to all the available server groups.
Either server-groups or all-server-groups is required in domain mode.
This argument is not applicable in the standalone mode.
-l - in case none of the required arguments is specified the command will
print all of the existing deployments in the repository. The presence of the -l switch
will make the existing deployments printed one deployment per line, instead of
in columns (the default).
And here's undeploy:
[standalone#localhost:9999 /] undeploy --help
SYNOPSIS
undeploy name [--server-groups=group_name (,group_name)* | --all-relevant-server-groups] [--keep-content]
DESCRIPTION
Undeploys the deployment with the given name and, depending on the arguments, removes
its content from the repository.
If the deployment name isn't specified, prints the list of all the existing deployments.
ARGUMENTS
name - the name of the deployment to undeploy.
--server-groups - comma separated list of server group names the undeploy command should apply to.
Either server-groups or all-relevant-server-groups is required in the domain mode.
This argument is not applicable in the standalone mode.
--all-relevant-server-groups - indicates that undeploy should apply to all the server groups
in which the deployment is enabled.
Either server-groups or all-relevant-server-groups is required in domain mode.
This argument is not applicable in the standalone mode.
--keep-content - by default undeploy, besides disabling the deployment, also removes its
content from the repository. The presence of --keep-content will only disable
the deployment w/o removing its content from the repository.
This argument can be used in both standalone and domain modes.
-l - in case the deployment name isn't specified, the presence of the -l switch
will make the existing deployments printed one deployment per line, instead of
in columns (the default).
The CLI In Action
Running the deploy or undeploy command without any arguments will list all the applications available. So your workflow to log in to the CLI and undeploy an application would be like this (simplified):
Change directory from EAP_HOME to the bin folder:
[user#home EAP_HOME]$ cd bin
Run the CLI logon script:
[user#host bin]$ ./jboss-admin.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
Instruct the API to connect (this can also be passed at runtime as ./jboss-admin.sh --connect).
[disconnected /] connect
Connected to standalone controller at localhost:9999
Run the undeploy command to display available applications.
[standalone#localhost:9999 /] undeploy
test.ear
Run the undeploy command to undeploy the application. In this case, the test.ear.
[standalone#localhost:9999 /] undeploy test.ear
Successfully undeployed test.ear.
Deployment Folder
If you are running an instance of AS7 as a development tool, and are using the deployment folder, you can simply delete the application. You will notice that a marker file is created, such as test.ear.failed, to signify the status of the application deployment.
With JBoss Application Server it's possible handle deployment with plain file operations on wars/ears in deploy dir.
Just ls to enumerate, delete to undeploy, copy to deploy and touch to redeploy. No server restart required.
Also for the newest version of JBoss Application Server 7 you can use CLI.
You can also try CLI GUI. The Deployments-->Undeploy menu option provides a pick list of deployments. A couple of clicks and you are done.
See https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
You dont have to restart the JBOSS server if you remove the WAR and EAR the application gets undeployed .
The article (http://docs.jboss.org/jbossas/docs/Clustering_Guide/4/html/clustering-intro-farm.html ) gives the perfect explanation of how it works.
Let all know if you have any questions about it .
We have been doing the development on Jboss the same way in our DEV , QA and Prod environment and have not faced any issues with it so-far.