Every time I add an user, it gets duplicated to all virtual hosts. I've been facing this issue for a while and found a way to solve it, see this post, it says I have to configure a separate database to each virtual host.
What I can't understand is why Ejabberd has this default behavior in first place, what is the benefit to do so?
And what about mod_mam? How do I configure it to store each message into its own database?
My ejabberd.yml (mod_mam configuration at line 113)
Thank you. :)
and found a way to solve it
Since recent ejabberd versions, you can use the new SQL schema, and configure ejabberd to use it, see in
https://docs.ejabberd.im/admin/configuration/#relational-databases
What I can't understand is why Ejabberd has this default behavior in
first place, what is the benefit to do so?
One possibility is the saved space for very big servers. Of course, when having many small servers, it's preferable to use one single database.
And what about mod_mam? How do I configure it to store each message
into its own database?
It's the same with this module than with the other ones: if you configure it to use 'sql' storage, and you configured ejabberd to use a certain database for host "example.net", and a different one for "example.com"..., then mod_mam will use the correct SQL database to store the MAM messages depending on the user that wants to store them.
Se the first and second example configs in section https://docs.ejabberd.im/admin/configuration/#virtual-hosting
On the other hand, if you use the new SQL schema, you only define one database, so those doubts do not appear.
[also asked in https://github.com/processone/ejabberd/issues/2752 ]
Related
We are using a long grown installation of ejabberd.
We all are using a jid called {username}#xmpp.foo.bar
Is there any possibility to alias this host with the domain?
I want, that i can login with baz#foo.bar but internaly ejabberd should connect as account baz#xmpp.foo.bar. This would prevent me from migrating all users and have all users to change there clients.
thanks for help.
If you want the clients to be able to login specifying as JID baz#foo.bar, then a DNS query for foo.bar must direct the client to the machine that handles ejabberd, and also in ejabberd.yml you must have:
hosts:
- "foo.bar"
Then the question is, how to use the existing information? I propose to modify the database content, replacing the old host with the new host.
If you use some SQL database, you may know already what queries to perform. Or you can dump the database to a text file, replace xmpp.foo.bar with foo.bar, and load it again.
If you use the internal Mnesia database, you can dump it to a text file, modify as I mentioned before, and then load the modified text file.
I'm looking into using CloudBees for some application prototyping. I am using free accounts right now, I am not paying any subscriptions at the moment.
The first step for me is to create a MySQL database to host my application's data. I've done so (and it was pretty easy!). I also use Liquibase to manage the database (I've started this work using local H2 databases for the pre-prototyping), and I've been able to construct everything as expected.
As part of checking whether liquibase created the tables, I brought up the MySQL database in NetBeans. And, it did function well. But I can also see other schemas as well as the schema I just created. They're all innocently named (test, test_6hob). But, I can see the tables and view their data.
My question is around the visibility of the data that's in the CloudBees database. Is the database created for the free accounts viewable to other people connecting to the same machine? Does this change if I use a paid account? Or is it more the nature of how the database was created? I can see other schemas (and their data) but I have no idea if other people can see mine? Is there a permissions-aspect I need to ensure I set? I've fairly ignorant with the inner-workings of MySQL.
While this is a prototype, were I to move into using CloudBees for production applications, I wouldn't want the data to be visible to anyone who happened to connect to the same database as my application. It's entirely possible that I'm missing something in this new cloud world. :)
Thanks for any info
All CloudBees MySQL databases are secured separately (although will be in shared instances unless you have a dedicated server) - they are not readable by any other account by default.
However, it is possible for the database owner to grant access to users from other accounts on that same database server if you really wanted to - even though it makes very little sense to do so (and your special user configuration will be lost during a failover).
So this is what has happened for the test databases that you can see - the database owner has opened up security on those databases / tables.
This question is probably off topic but i'll bite anyway. The database data is private to your account. Actual hardware/vm's maybe shared but the data/database is not.
I was given access to a cluster today along with a front-end. The person who gave me access tells me I cannot start anything on the front-end and that I should submit everything as a job. Now I have no idea what that means but I'm thinking that I am not supposed to start MySQL on the front-end. If that is the case, how can I even use the database?
Is there a way I can add indexes without using the client-server? Or is it even possible to use a database in a cluster setup where I can only submit jobs?
I am guessing the person means that the client is actually executed as a "job". you might want to find out how they program the cluster.
We need to deploy application(developed by Java) WAR file in client place which make use of MySql 5.0. But we would like to restrict the client (the application owner, not the webpage visitor) from modifying any data in the database. Is there any way to protect data. The client can make use of the application but they should not be able to change any value in database. How to do that?
Manage Role/User permissions
Create an sql user (you should already have one), which will have only SELECT permission. So it would be something like
GRANT SELECT ON db_base.* TO db_user#'localhost' IDENTIFIED BY 'db_passwd';
http://kb.mediatemple.net/questions/788/HOWTO:+GRANT+privileges+in+MySQL
http://blog.wl0.org/2010/01/managing-mysql-grants/
http://www.ntchosting.com/mysql/grant.html
Check links below for further reading
FOR MySQL
Best Practice for Designing User Roles and Permission System?
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.devshed.com/c/a/MySQL/MySQL-User-Account-Management/
Can't set permissions on MySQL user
http://www.aquafold.com/d7/docs/BD5C99E4-3B55-C812-8318-6338A9A89ED9.html
FOR SQL Server.
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.mssqlcity.com/Articles/Adm/SQL70Roles.htm
http://www.sql-server-performance.com/articles/dba/object_permission_scripts_p1.aspx
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1061781.html
http://www.databasejournal.com/features/mssql/article.php/2246271/Managing-Users-Permissions-on-SQL-Server.htm
This is impossible; if you deploy the application at the client, he will have the credentials and will be able to log into the MySQL database and pretent he is the application. And thus he can make any change to the database that your application can.
The only way to solve this securely is to make a tier between the client and your MySQL database, and make sure that you control this so that it is only possible to make 'legal' changes.
Just write the code accordingly so that the user doesn't have any chance to modify the database? I.e. the code doesn't execute any INSERT or UPDATE and/or controls the access based on a login/role.
I honestly really don't forsee any problems here, or the code must be prone to SQL injection attacks.
Update: The above answer is actually irrelevant since the question is clarified. Turning into Community Wiki.
First off, I realize that there is no such thing as a perfectly secure solution (and even if there were, its usability would be crap).
That said, how do you protect your MySQL database from being compromised by someone downloading your code and picking through it? Based on my experience with PHP, it seems obligatory to store it within the code at some point or another, which sends up flags for me. I can see where refactoring to obfuscate variable, constant, and (user-defined) function names could be beneficial, but in the end it'd still be possible to trace through it and find the file with the DB login information.
Ideas?
Usually the MySQL auth information is stored in an external configuration file. The MySQL user used by the web-based app is given limited permissions such as SELECT, INSERT, UPDATE, DELETE and not given permissions such as ALTER, DROP, DELETE. If you want to release the code to the public you would not include your private config file, but a generic/instructional/minimal config file instead.
Storing the MySQL auth info in an encrypted format is somewhat silly, as you'd need to store the private key / unencryption locally as well. If it is trivial for an unauthenticated user to view the code or configuration files on your server the problem isn't the code - it's your server setup & config.
Security can be assisted by storing any hard-coded information (in config files or scripts) outside of the web-root, and by suppressing (on the production code) error messages. That way, hopefully, your users won't see that userValidate() expects exactly three paramaters.
pygorex1 is correct, you should use external configuration files where "external" means a file outside the web root. So even if there would be a configuration error in your web server which would allow the user to see your source code, they would not be able to see the database credentials since they cannot be accessed directly via the browser.
pygorex1 is also right on the user permissions. Limiting the mysql user's access to a minimum is always preferred. Even if a hacker would get the your mysql password and username, he would not be able to do significant damage if the user permissions are only limited to eg SELECT-queries. One thing he forgot to mention was that the mysql user should only be allowed to log in from localhost (or from whatever host the web application is on), never use wildcards in the allowed hosts.