While meddling with an experimental Dreamfactory 2.1 installation, the user service was accidentally disabled through the admin console. The message when trying to log in is
Service user is deactivated
How to get around this problem? Is there a configuration file or something that I need to edit to get this back on? After a bit of probing I saw this in the table called "service" in MySQL db(bitnami_dreamfactory).
+-------------------------+-----------+
| name | is_active |
+-------------------------+-----------+
| system | 1 |
| api_docs | 1 |
| files | 0 |
| db | 0 |
| email | 0 |
| user | 0 |
| mysql | 0 |
| mongodb | 1 |
| scr-insert | 1 |
| testdb | 1 |
| test-mlabs | 1 |
+-------------------------+-----------+
Can I just go ahead an issue an update statement to set 0 to 1, for 'user' service?
Thanks,
M&M
Yes, and then clear the application cache using 'php artisan cache:clear'.
Related
In TDengine shell, any upper case letter is automatically converted to a lower case letter like below:
taos> create database TEST;
Query OK, 0 of 0 row(s) in database (0.002404s)
taos> show databases;
name | created_time | ntables | vgroups | replica | quorum | days | keep | cache(MB) | blocks | minrows | maxrows | wallevel | fsync | comp | cachelast | precision | update | status |
====================================================================================================================================================================================================================================================================================
test | 2021-11-16 16:07:47.410 | 0 | 0 | 1 | 1 | 10 | 3650 | 16 | 6 | 100 | 4096 | 1 | 3000 | 2 | 0 | ms | 0 | ready |
db | 2021-11-16 13:30:46.858 | 13 | 1 | 1 | 1 | 10 | 3650 | 16 | 6 | 100 | 4096 | 1 | 3000 | 2 | 0 | ms | 0 | ready |
Query OK, 2 row(s) in set (0.001591s)
taos> use test;
Database changed.
taos> create table STB(ts timestamp, c1 int) tags(t1 int);
Query OK, 0 of 0 row(s) in database (0.002349s)
taos> show stables;
name | created_time | columns | tags | tables |
============================================================================================
stb | 2021-11-16 16:08:34.322 | 2 | 1 | 0 |
Query OK, 1 row(s) in set (0.001501s)
Is there any way to create a database name or table name in upper case letters?
upper case database name is not supported in TDengine database, but upper case table name is supported by use following SQL:
taos> create table `UPPER_CASE_TABLE_NAME` (ts timestamp, c1 int); Query OK, 0 of 0 row(s) in database (0.008671s)
taos> show tables;
table_name | created_time | columns | stable_name | uid | tid | vgId |
==========================================================================================================================================================
UPPER_CASE_TABLE_NAME | 2022-05-05 18:40:21.011 | 2 | | 40813871670686384 | 2 | 145 |
Query OK, 1 row(s) in set (0.007461s)
Let's say I have the following FitNesse page:
!| com.myproject.fitnesse.fixtures.SSHFixture |
| set host | ${hostSi1} |
| set port | ${port} |
| set user | ${user} |
| connect |
| show | run command | pwd |
| disconnect |
www.<variable>.com
The page contains one table and a link. The table will execute the console command pwd. How do I save the result of that command in a FitNesse Variable? I want then to use the variable within the same page. For example in the mentioned link.
Some resources are mentioning SLIM style, but I have no idea how to accomplish that in my case:
Using data from fitnesse table as a variable
#Fried Hoeben: Yes its a script. Got a solution from my colleague.
Let's say you have Fixture for DB stuff and there's method called 'execute query' which will return result of the query.
Setting value to variable 'myname' so we could use in another fixture table as '#{myname}'.
!| com.mystest.fitnesse.fixtures.DBFixture |
| set database | ${dbName} |
| set username | ${dbUser} |
| set password | ${dbPassword} |
| connect | ${dbType} | to | ${dbUrl} | database | ${dbPort} |
| set | myname | execute query | SELECT name FROM customer WHERE id = 1 |
| disconnect |
Use of variable 'myname':
!| com.mytest.fitnesse.fixtures.SSHFixture |
| set host | ${host} |
| set port | ${port} |
| set user | ${user} |
| connect |
| show | execute|echo #{myname} |
| disconnect |
Not sure if the feature of set is part of fitnesse default impl. or of our company implementation.
i did an upgrade on my server for my Docker MARIADB with:
docker-compose pull
docker-compose up -d
My version before:
Server version: 10.2.14-MariaDB-10.2.14+maria~jessie mariadb.org binary distribution
SHOW VARIABLES LIKE "%version%";
+-------------------------+--------------------------------------+
| Variable_name | Value |
+-------------------------+--------------------------------------+
| innodb_version | 5.7.21 |
| protocol_version | 10 |
| slave_type_conversions | |
| version | 10.2.14-MariaDB-10.2.14+maria~jessie |
| version_comment | mariadb.org binary distribution |
| version_compile_machine | x86_64 |
| version_compile_os | debian-linux-gnu |
| version_malloc_library | system |
| version_ssl_library | OpenSSL 1.0.1t 3 May 2016 |
| wsrep_patch_version | wsrep_25.23 |
+-------------------------+--------------------------------------+
My version now:
Server version: 10.3.9-MariaDB-1:10.3.9+maria~bionic mariadb.org binary distribution
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| innodb_version | 10.3.9 |
| protocol_version | 10 |
| slave_type_conversions | |
| system_versioning_alter_history | ERROR |
| system_versioning_asof | DEFAULT |
| version | 10.3.9-MariaDB-1:10.3.9+maria~bionic |
| version_comment | mariadb.org binary distribution |
| version_compile_machine | x86_64 |
| version_compile_os | debian-linux-gnu |
| version_malloc_library | system |
| version_source_revision | ca26f91bcaa21933147974c823852a2e1c2e2bd7 |
| version_ssl_library | OpenSSL 1.1.0g 2 Nov 2017 |
| wsrep_patch_version | wsrep_25.23 |
+---------------------------------+------------------------------------------+
So it seems it was a upgrade from 10.2 to 10.3.
Upgrading from MariaDB 10.2 to MariaDB 10.3
Now i get the following error in "docker-compose logs"
2018-09-28 13:03:38 0 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name. Please run mysql_upgrade
2018-09-28 13:03:38 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name. Please run mysql_upgrade
The database is working as expected. What to do to get rid of this error?
While I was writing the question I was able to fix it myself. If you also facing this problem:
connect to the docker database container:
docker exec -u 0 -i -t CONTAINER_NAME /bin/bash
run mysql_upgrade like written in the error message:
mysql_upgrade --user=root --password=xxyy --host=localhost
I did a restart of the docker compose with:
docker-compose stop
docker-compose start
I found numerous sites explaining ssh port forwarding, ssh reverse proxy, ssh multiplexing etc. involving sshpiper, sslh, running a ssh socks server, just configuring the local SSH server an so on..
so I'm quite puzzled right now and might ask a very common and/or simple question:
As you might already guess from the title I want to set up a git server (GitLab) inside a docker container listening for SSH connections on port 22 without having to use a different port for default ssh operations (terminal, scp, etc..) on the host (as suggested here)
I.e.
ssh alice#myserver.org should still be possible as well as
git clone git#myserver.com:path/to/project
and I don't want to do any setup on the client computer
If you prefer a picture:
+------ myserver.org --------+
| +----+ +- typical -+ |
+--------+ alice#myserver.org:22 | | | | SSH | |
| client | ----------------------> -+--+----+---->| service | |
+--------+ all names but `git` | | ? | +-----------+ |
| | | |
| | ? | +- docker --+ |
+--------+ git#myserver.org:22 | | | | with | |
| client | ----------------------> -+--+----+---->| GitLab | |
+--------+ only user `git` | | | | | |
| +----+ +-----------+ |
+----------------------------+
Can you tell me what's the recommended/most common way to do this? This question sounds promising but the answer seems to configure the client (which I want to avoid)
This project may help you.
https://github.com/tg123/sshpiper.
SSH Piper works as a proxy-like ware, and route connections by username, src ip , etc.
+---------+ +------------------+ +-----------------+
| | | | | |
| Bob +----ssh -l bob----+ | SSH Piper +-------------> Bob' machine |
| | | | | | | |
+---------+ | | | | +-----------------+
+---> pipe-by-name--+ |
+---------+ | | | | +-----------------+
| | | | | | | |
| Alice +----ssh -l alice--+ | +-------------> Alice' machine |
| | | | | |
+---------+ +------------------+ +-----------------+
Downstream SSH Piper Upstream
First of all, thanks for reading TheDockerExperts blog , hope our articles help you! Let me explain how we do SSH proxy in our company.
We have HAproxy that listens TCP 22 port and sends traffic to GitLab server, on host we have custom SSH port. Unfortunately as we use TCP balancing in this case, there is no way to create balancer based on domain names and users. You can take small VPS , spin up HAproxy on it and use it to balance your GIT traffic.
Hope this will help you!
Stack is Rails 3 / Postgres + mongrel. I recently had to increase the connection pool because hits on one of the mongrels were always timing out. I reasoned that with 3 mongrels + a delayed_job running on each, I'd need 6 connections in the pool (it was set to 5). I increased this to 10 in database.yml and it resolved the timeout issues, now though when I monitor connections in PG I am seeing this sort of thing;
SELECT datname,usename,procpid,client_addr,waiting,query_start,current_query FROM pg_stat_activity;
db1 | www-data | 8658 | | f | 2014-03-19 10:03:54.084825+00 | <IDLE>
db1 | www-data | 9071 | | f | 2014-03-19 09:58:42.306558+00 | <IDLE>
db1 | www-data | 8721 | | f | 2014-03-19 10:03:53.980691+00 | <IDLE>
db1 | www-data | 8722 | | f | 2014-03-19 10:03:53.874443+00 | <IDLE>
db1 | www-data | 8733 | | f | 2014-03-19 10:04:20.380137+00 | <IDLE>
db1 | www-data | 9080 | | f | 2014-03-19 10:00:54.157541+00 | <IDLE>
db1 | www-data | 10843 | | f | 2014-03-19 10:04:18.506355+00 | <IDLE>
#and so on and so on for more than 20 instances...
It baloons up to more than 20 connections and seemingly isn't closing them (I'm assuming that the presence of still means they're open, just not doing anything). It does seem to go up and down, so some connections are being closed.
I thought rails/activerecord was supposed to close its connections automatically but this doesn't seem to be the case.
Have I read this correctly? Do I have a leak somewhere? What could be causing it?
When using ActiveRecord transactions outside of actions initiated by a controller e.g. in a delayed job, you must use the following syntax to ensure connections are returned to the pool
ActiveRecord::Base.connection_pool.with_connection do
#your code here
end