kong error using deck: cannot create or update 'services' entities when not using a database - rhel7

I have set up kong in dbless mode on RHEL by following the below documentation
https://docs.konghq.com/gateway/latest/install-and-run/rhel/
Kong gateway is successfully started. Below are the configurations I added in kong.conf file where database is turned to off and path to declarative kong.yaml is specified
declarative_config = /temp/kong/kong.yml
database = off
Also, below is current .yaml file where I created a service using below link
https://docs.konghq.com/gateway/2.8.x/get-started/comprehensive/expose-services/
_format_version: "1.1"
services:
- host: mockbin.org
name: example_service
port: 80
protocol: http
routes:
- name: mocking
paths:
- /mock
strip_path: true
I have also installed deck to sync this the declarative configuration.
However, when I use the deck sync command to add this service to kong, I get below error
creating service example_service
Summary:
Created: 0
Updated: 0
Deleted: 0
Error: 1 errors occurred:
while processing event: {Create} service example_service failed: HTTP status 405 (message: "cannot create or update 'services' entities when not using a database")
Kindly need ideas on what could be wrong as I believe we can create a service in dbless mode, and I also think that this is the declarative format which should work. Looking forward to hear. Thanks

Kindly need ideas on what could be wrong as I believe we can create a service in dbless mode, and I also think that this is the declarative format which should work. Looking forward to hear. Thanks
You are correct that we can create a service in dbless mode, however the approach will be different.
If you already have the new config file in yaml format. you can load it to Kong using /config endpoint
I also think that decK should be process-agnostic and can be used with both db and dbless mode, But as it stands, loading yaml config file with /config endpoint looks like the best option.

Related

Salt state to enable re-run systemd service

I am trying to craft a salt state file to simply ensure-enabled and re-run my one-shot service. I thought it would be nice to re-run if any of the dependent files changed, but honestly this is simple enough and the short-lived service is almost never going to be running when I want to update.
Current attempt:
myown-systemd-service-unit-file:
...
myown-systemd-service-executable-file:
...
myown-service:
systemd.force_reload:
- name: myown
- enable: True
- watch:
- myown-systemd-service-unit-file
- myown-systemd-service-executable-file
is failing at with errror:
----------
ID: myown-service
Function: systemd.force_reload
Name: myown
Result: False
Comment: State 'systemd.force_reload' was not found in SLS 'something.myown'
Reason: 'systemd.force_reload' is not available.
Changes:
By enable, I mean to have the equivalent of this CLI call be applied:
sudo systemctl enable myown.service
Relevant docs: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.systemd_service.html#module-salt.modules.systemd_service
The systemd_service module is an execution module, and the syntax to use such modules is slightly different. The state declaration you are using is for state modules. Also, the example from the documentation points to use of service.force_reload rather than systemd.force_reload.
salt '*' service.force_reload <service name>
Considering all this, the below example restarts and enables myown service when the service unit file changes.
myown-service:
module.run:
- service.restart:
- name: myown
onchanges:
- file: myown-systemd-service-unit-file
- service.enable:
- name: myown
Note that I've used restart instead of force_reload to bounce the service. Also I'm using onchanges for file module as you haven't shown how you manage the two files. You can use the appropriate module and state IDs.

How to configure Spring Cloud Configuration Server without the git profile?

I'm attempting to run Spring Cloud Configuration Server, working through the examples in a book (Manning's Spring Microservices in Action), but updating to the latest versions: Java 17, spring-boot-starter-parent 2.6.1, with Spring Cloud 2021.0.0-RC1.
Each time I try to start the server, I get this error:
***************************
APPLICATION FAILED TO START
***************************
Description:
Invalid config server configuration.
Action:
If you are using the git profile, you need to set a Git URI in your configuration. If you have set spring.cloud.config.server.bootstrap=true, you need to use a composite configuration.
I am not using the git profile. I have tried two different profiles: native (with config files on the classpath) and vault (with a Hashicorp Vault server running locally). My latest /src/resources/bootstrap.yml contains the following:
spring:
application:
name: config-server
profiles:
active: vault
cloud:
config:
server:
vault:
port: 8200
host: 127.0.0.1
kvVersion: 2
server:
port: 8071
My best guess is that the bootstrap.yml file isn't getting picked up at server startup, and perhaps the git profile is a default. How can I remedy this?
OK, it looks like the problem here is that newer versions of Spring Cloud Configuration Server don't look for the bootstrap.yml file by default. There are a few different ways to solve it. The easiest is just to move all the properties to an application.yml/application.properties instead.
Another alternative is (found at NEWBEDEV here) is to include a dependency that implements the "legacy" bootstrap behavior:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
add the following into application.properties file.
spring.application.name=techefx-spring-cloud-config-server
spring.cloud.config.server.git.uri=https://github.com/techefx/environment-variable-repo.git
server.port= ${port:8888}
Please go through the link below:
Spring Cloud Config File System Backend Issue (not reading properties from the file)

Concourse unauthorized error pushing to Artifactory using docker-image-resource

I'm trying to use Concourse to grab a dockerfile defintion from a git repository, do some work, build the docker image, and push the new image to Artifactory. See below for the pipeline definition. At this time I have all stages up to the artifactory stage (the one that pushes to Artifactory) working. The artifactory stage exits with error with the following output:
waiting for docker to come up...
sha256:c6039bfb6ac572503c8d97f42b6a419b94139f37876ad331d03cb7c3e8811ff2
The push refers to repository [artifactory.server.com:2077/base/golang/alpine]
a4ab5bf94afd: Preparing
unauthorized: The client does not have permission to push to the repository.
This would seem straight-forward as an Artifactory permissions issue, except that I've tested locally with the docker cli and am able to push using the same user/pass as specified within destination_username and destination_password. I double checked the credentials to make sure I'm using the same ones and find that I am.
Question #1: is there any other known cause for getting this error? I've scoured the resource github page without finding anything. Any ideas why I may be getting the permissions error?
Without having an answer to the above question, I'd really like to dig deeper into troubleshooting the problem. To do so I use fly hijack to get a shell in the corresponding container. I notice that docker is installed on the container, so next step I think would be to do a docker import on the tarball for the image I'm trying to push and then perform a docker push to push it to the repo. When attempting to run the import I get the error:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is
the docker daemon running?
Question #2: Why can't I use docker commands from within the container? Perhaps this has something to do with the issue I'm seeing with pushing to repo when running the pipeline (I don't think so)? Is it because the container isn't running with privilege? I thought that the privileged argument would be supplied in the resource type definition, but if not, how can I run with privilege?
resources:
- name: image-repo
type: git
source:
branch: master
private_key: ((private_key))
uri: ssh://git#git-server/repo.git
- name: artifactory
type: docker-image
source:
repository: artifactory.server.com:2077/((repo))
tag: latest
username: ((destination_username))
password: ((destination_password))
jobs:
- name: update-image
plan:
- get: image-repo
- task: do-stuff
file: image-repo/scripts/do-stuff.yml
vars:
repository-directory: ((repo))
- task: build-image
privileged: true
file: image-repo/scripts/build-image.yml
- put: artifactory
params:
import_file: image/image.tar
Arghhhh. Found after much troubleshooting that the destination_password wasn't being picked up properly due to special characters and a lack of quotes. Fixed the issue by properly setting the password within yaml file being included with the --load-vars flag.

Kong refuses to recognise custom plugin as enabled

I was developing a Custom plugin for Kong.
To start off I followed guidelines listed in this tutorial
http://streamdata.io/blog/developing-an-helloworld-kong-plugin/
Few changes that I made along the way were changing dependency in the rockspec file for "lrexlib-pcre" from version 2.8.0-1 to 2.7.2-1 due to compilation problems that I faced with 2.8.0-1 version.
Please note that I am working in the next branch. The master branch has version 2.7.2-1 listed.
The tutorial assumes Kong version 0.4.2-1 while I am working with Kong version 0.5.2-1.
I have listed my plugin in kong.yml. Last listed is helloworld plugin
plugins_available:
- ssl
- jwt
- acl
- cors
- oauth2
- tcp-log
- udp-log
- file-log
- http-log
- key-auth
- hmac-auth
- basic-auth
- ip-restriction
- mashape-analytics
- request-transformer
- response-transformer
- request-size-limiting
- rate-limiting
- response-ratelimiting
- helloworld
I have listed the helloworld files in rockspec file at the last.
["kong.plugins.helloworld.handler"] =
"kong/plugins/helloworld/handler.lua",
["kong.plugins.helloworld.access"] = "kong/plugins/helloworld/access.lua",
["kong.plugins.helloworld.schema"] = "kong/plugins/helloworld/schema.lua"
Compilation is successful but kong refuses to list helloworld plugin as available in the node. All other builtin plugins are shown as available in the server
I tried enabling the plugin anyway with mock api. It doesn't work as expected and trying to restart kong lists error
nginx: [error] [lua] init_by_lua:5: Startup error:
/usr/local/share/lua/5.1/kong.lua:82: You are using a plugin that has
not been enabled in the configuration: helloworld [INFO] dnsmasq
stopped [ERR] Could not start Kong
I know there were some breaking changes introduced in Kong version 0.5. I followed the changelog, but I found nothing that would help.
Am i missing a setting a configuration somewhere?
Any help would be appreciated.
Try the following in your kong.yml:
custom_plugins:
- helloworld
I fixed this issue by adding things in custom_plugins and lua_package_path.
Here are the steps to enable and use custom plugin in kong Env.
1 - Add custom plugin name in --- custom_plugins = hello-world
2 - Install hello-world plugin by using following steps ---
If you have source code of your plugin then move into it and execute the command --- "luarocks make"
it will install your plugin.
now you have to execute a command "make install-dev" make sure your plugin have makefile like as --
Once you execute this command "make install-dev". it will create lua file at a location something like that -
/your-plugin-path/lua_modules/share/lua/5.1/kong/plugins/your-plugin-name/?.lua
just copy this path and add it into the kong configuration file in lua_package_path
Something like that --
lua_package_path=/your-plugin-path/lua_modules/share/lua/5.1/kong/plugins/your-plugin-name/?.lua
Now you done your job.
Just start kong -- kong start --vv
You will see that the plugin loaded into kong plugin env.
#Enjoy

Alfresco Share - Unable to change the default port number

I am trying to configure Alfresco Community 3.3 on a port other than its default port of 8080. I need it to run on 8989. I think I have change all instances of 8080 (where it is mentioned in configuration files) to 8989, and I am able to access Alfresco Explorer okay. So far so good.
But, when I try to access http://localhost:8989/share I get the following error
java.io.IOException: Unable to test document path:
alfresco/site-data/configurations/slingshot.site.configuration.xml in
remote store: alfresco due to error: 404
The files I have changed are as follows:
tomcat/conf/server.xml
tomcat/shared/classes/alfresco/web-extension/share-config-custom.xml
tomcat/webapps/alfresco/WEB-INF/classes/alfresco/file-severs.xml
tomcat/webapps/alfresco/WEB-INF/classes/alfresco/repository.properties
tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystem/sysAdmin/default/sysadmin-parameter.properties
tomcat/webapps/alfresco/wsdl/access-control-service.wsdl
tomcat/webapps/alfresco/wsdl/administration-service.wsdl
tomcat/webapps/alfresco/wsdl/action-service.wsdl
tomcat/webapps/alfresco/wsdl/authentication-service.wsdl
tomcat/webapps/alfresco/wsdl/authoring-service.wsdl
tomcat/webapps/alfresco/wsdl/classification-service.wsdl
tomcat/webapps/alfresco/wsdl/content-service.wsdl
tomcat/webapps/alfresco/wsdl/dictionary-service.wsdl
tomcat/webapps/alfresco/wsdl/repository-service.wsdl
virtual-tomcat/conf/server-minimal.xml
virtual-tomcat/conf/server.xml
Have I missed something obvious?
(Please make no suggestions about upgrading......)
I think you have overdone it.
According to
http://wiki.alfresco.com/wiki/Changing_Default_Port_Configuration
you should only change it in share-config-custom.xml
Change all the files back but share-config-custom.xml
Four are the files to be changed in Alfresco 5.2 in order to set the various ports:
[alfresco-community_instDir]\properties.ini
[alfresco-community_instDir]\tomcat\conf\server.xml
[alfresco-community_instDir]\tomcat\shared\classes\alfresco-global.properties
[alfresco-community_instDir]\tomcat\webapps\share\WEB-INF\classes\alfresco\share-cmis-config.xml

Resources