I have a problem with configuring standalone custom registry in WebSphere Application Server (Cluster environment). I have followed all steps from IBM manual:
I have implemented UserRegistry interface in DataBaseRegistry class
I have copied .jar to the lib/ext folder of WebSphere
I have assigned all necessary properties on Global Security page
and while trying to assign Standalone Custom Registry as current I got a following error:
Validation failed: Error occurred in RequiredModelMBean while trying to invoke operation getUsers
The funny part is that I followed all of those steps in a standalone version of WebSphere (not clustered) and it is working properly (so the problem is not in the code). Another thing is that there is nothing in the log files. I can see that getUsers is called and then no Exception or anything.
UPDATE: I resolved my problem. I was propably not 100% focused.
It tourned out that I forgot to copy additional jar with JDBC drivers to lib/ext that allow to connect to MSSQL.
LESSON LEARNED: Do not start important configuration work on Friday after lunch ;)
Related
I'm running jira in openshift using the basic image from atlassian: https://hub.docker.com/r/atlassian/jira-software
So far most things work fine.
I installed a plugin using the web ui which worked as well.
But now I'm running into an issue when a pod is restarted. The pod uses the image and naturally (as specified) my plugin is not installed anymore. I can install the plugin via webservice calls and register it as an osgi module for jira. But I don't want to do this manually. Building a pipeline or jon for this is quite easy (I'm thinking jenkins or ansible tower). But I so far I didn't find a way to trigger this pipeline after the pod is started (or better after jira is started).
Anyone got an idea how to handle this?
Thanks and best regards. Sebastian
Why not create a custom image based on the Atlassian image with everything you need installed?
As far as I know, there isn't a way to trigger a pipeline when a Pod is started; only Webhook, Image Change, and Config Change triggers are available. You'll need to write a Jenkinsfile to script all of the installation and setup you want, but then that can be triggered in one of the three ways mentioned.
I'm thinking an Image Change trigger would work best for you, so when the latest version of Atlassian's image comes out, you can run your pipeline to set everything up on the latest version.
Also, just curious, but do you have some persistent storage attached to the Jira pod? If not, you'll lose everything in Jira if the Pod dies; that means tickets, boards, comments, everything.
Update:
Looking at this page, it looks like most of the stuff you're trying to persist is stored in jira-home, so maybe mounting that as a persistent volume will be a good solution for you.
You're correct that the tickets are stored in the database, but I'm guessing the database connection settings are getting wiped when the Pod is cycled.
The jira-home directory stores your application and database connection settings, as well as a subdirectory for your plugins.
dbconfig.xml
This file (located at the root of your JIRA home directory) defines
all details for JIRA's database connection. This file is typically
created by running the JIRA setup wizard on new installations of JIRA
or by configuring a database connection using the JIRA configuration
tool.
You can also create your own dbconfig.xml file. This is useful if you
need to specify additional parameters for your specific database
configuration, which are not generated by the setup wizard or JIRA
configuration tool. For more information, refer to the 'manual'
connection instructions of the appropriate database configuration
guide in Connecting JIRA to a database.
jira-config.properties
This file (also located at the root of your JIRA home directory)
stores custom values for most of JIRA's advanced configuration
settings. Properties defined in this file override the default values
defined in the jpm.xml file (located in your JIRA application
installation directory). See Advanced JIRA configuration for more
information.
In new JIRA installations, this file may not initially exist and if
so, will need to be created manually. See Making changes to the
jira-config.properties file for more information. This file is
typically present in JIRA installations upgraded from version 4.3 or
earlier, whose advanced configuration options had been customized
(from their default values).
plugins/
This is the directory where plugins built on Atlassian's Plugin
Framework 2 (i.e. 'Plugins 2' plugins) are stored. If you are
installing a new 'Plugins 2' plugin, you will need to deploy it into
this directory under the installed-plugins sub-directory.
'Plugins 1' plugins should be stored in the JIRA application
installation directory.
This directory is created on JIRA startup, if it does not exist
already.
I have an old Debian Compute Engine instance (created and running since December 2013) and got an email warning about the turndown of Legacy GCE and GKE metadata server endpoints (more details at https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server).
I followed the directions for locating the process and found that the requests were coming from /usr/share/google/google_daemon/manage_addresses.py. The script seems to be the same as what's at https://github.com/gtt116/gce/blob/master/google_daemon/manage_addresses.py (also with what's in that directory).
I don't recall installing this, so I'm imaging it came with the provided Debian image I used in 2013.
Does anyone know what this manage_addresses.py script is, what it does, and what I should do with it now that the legacy metadata server endpoints are turning down? Is it safe to just stop running it? Or is there a new script I should replace it with? Or should I just try to update it myself to use the new endpoint?
I dug around and was able to trace /usr/share/google/google_daemon/manage_addresses.py as being installed by a package called google-compute-daemon. A search for that brought me to https://github.com/GoogleCloudPlatform/compute-image-packages#troubleshooting which explains that google-compute-daemon has been replaced with python-google-compute-engine. That led me to https://cloud.google.com/compute/docs/images/install-guest-environment . I followed the instructions there and manually installed the guest environment.
I noticed during installation that it said it was removing the google-compute-daemon package (and a packaged called google-startup-scripts), so this seems like the right thing. And I'm no longer seeing any requests to the legacy endpoints. So it seems like at some point the old guest environment failed to update.
TLDR; If you have this problem, follow the instructions at https://cloud.google.com/compute/docs/images/install-guest-environment#installing_guest_environment to manually update the guest environment.
The main issue here makes it different from other available problems and solutions (here) is that, I am working with a previously working M# project and right now after upgrading to M# v4.8.334 (or maybe some other modifications regarding Visual Studio 2017 installation), if I want to add any new fields to any entity in MSharp IDE, it gives the following error
Base issue: The partner transaction manager has disabled its support
for remote/network transactions. (Exception from HRESULT: 0x8004D025)
One important point to note is that for newly created projects it is working correctly without this exception so my DTC settings and service are configured correctly.
Updated:
my main issue was my app SQL database connection string which I have changed it from default local instance in web app web.config , to remotely hosted production database and after changing back that connection string this issue gets resolved
it is useful to note that there is another database with .DesignTime suffix which is created beside your app .temp database and I searched for designTime in content of files in the project and did not found any trace of it, so it seems that you do not have much control over it and in design time maybe M# IDE is looking for it beside you db, beside the fact that DTC service must be running on remote server
for anyone looking for more correct DTC setting which is recommended by MSharp company note the following image
I am attempting to implement a custom security extension for an instance of SQL Reporting Server 2012, and am having some trouble. This extension is to hook into an existing application that uses Forms authentication.
I've implemented the appropriate required interfaces (IAuthenticationExtension and IAuthorizationExtension) and, as far as I know, have changed the configuration files appropriately (as per MSDN's instructions). Also, I've copied the assemblies over to the report server (to both the ReportServer and ReportManager's bin directories).
The error I'm getting is:
library!ReportServer_0-4!44c!11/20/2015-15:41:12:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: Could not load Authentication extension, Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. ;
I've verified that reverting back to the report server's default settings (and thus changing the authentication mode back to Windows) works, so there is nothing wrong with the installation of the software. I've also read this question over at ServerFault, but I don't really want to have to rebuild SSRS if I don't have to.
At this point, I'm not trying to do anything fancy--I'm just trying to make sure my extension is loading properly.
Thanks for any help.
I in fact found the problem. Make sure when you're setting up your custom extension in rsreportserver.config that you specify Forms for the Name attribute for the Extension element (if you are doing Forms authentication). This is under the Extensions parent element
For example,
<Authentication>
<Extension Name="Forms" Type="<TypeName>,<AssemblyName>"/>
</Authentication>
I'm guessing since SSRS loads specific HTTP modules to handle various forms of authentication (e.g. Windows, Forms, Passport, etc.), it is looking for the name of one of those modules when adding a custom extension.
From MSDN:
In practice, deploying a custom authentication extension requires multiple steps that include copying assemblies and application files, modifying configuration files, and testing.
It sounds like you have modified the report server configuration, but the error seems to indicate that the custom authentication assembly is not available on the report server - has this been installed on the server?
I'm forced to use a Websphere Application Server 6.1.
I configured some system properties using the admin console, but now the application server doesn't start at all. Which also means I can't access the admin console to remove the system properties which probably cause the problem.
How can I remove the system properties without actually starting the application server?
In case it is of any relevance, the system properties are:
-Dcom.sun.management.jmxremote.port=3333
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
If finally found the file where this kind of configuration is stored. On my machine it is
C:\Program Files\IBM\SDP\runtimes\base_v61\profiles\was61profile1\config\cells\ddea1846Node01Cell\nodes\ddea1846Node01\servers\server1\server.xml
In that file one can find the setting in question and remove it.