Symfony2 DBAL & ORM Setup - orm

So I have been fiddling around with Symfony2 all morning and read the main documentation or at least half of it. I am stuck at anything related to Database.
My simple question is: do we make the database structure before hand or not?
Documentation says make the Entity class and then generate the database table using database:create on CLI. I followed and made a blog entity class with orm annotations.
ran the command:
php app/console doctrine:database:create
Warning: PDO::__construct(): [2002] No such file or directory (trying to connect via unix:///var/mysql/mysql.sock) in /Applications/MAMP/htdocs/flairbagSy2/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 36
Could not create database for connection named blog
SQLSTATE[HY000] [2002] No such file or directory
I think this has something to do with the location of the mysql socket file but I don't know how to change the path of the socket file in Symfony2's configuration.
If anyone could just point out where do I change the path of socket file.
I once had a similar problem with CakePHP and the simple fix was to add a port key to the db connection array:
var $default = array(
'driver' => 'mysql',
'persistent' => false,
'host' => 'localhost',
'login' => 'root',
'password' => 'root',
'database' => 'cake',
'port' => '/Applications/MAMP/tmp/mysql/mysql.sock',
);
How do I do that in Symfony2.

The doctrine:database:create command will not populate the structure of the tables but rather create the database on your database manager like MySQL. To populate the database structure, use the doctrine:schema:create command for the initial creation of the structure and the doctrine:schema:update --force command when you want to update the structure after you made some modifications to the annotations.
As you have mentionned, you need to configure some parameters in Symfony2 for Doctrine to work correctly. Those parameters need to be set in the config.yml configuration file that you can find in the app/config folder of the standard Symfony2 distribution. Here's a sample of the configuration you need to add to the config.yml file:
# Doctrine Services Configuration
doctrine:
dbal:
default_connection: default
connections:
default:
driver: pdo_mysql
host: localhost
port: 3396
dbname: dbname_dev
user: dbname_dev
password: yourpassword
logging: "%kernel.debug%"
orm:
auto_generate_proxy_classes: "%kernel.debug%"
default_entity_manager: default
entity_managers:
default:
mappings:
AcmeBundle: ~
The first part of the configuration, the dbal part, is used configure your database connection information. I would suggest you to first test the connection with the root account of your database and then when everything is working well, change the settings to use a dedicated user. This way, you are sure that you don't have some privileges problems or other kind of problems that could be related to the dedicated user.
The second part, the orm part, is use to configure the mapping of your entities to the database. This part is required if you want Symfony2 to populate the database structure automatically. Replace AcmeBundle with the name of your bundle in the sample above to enable the orm functionalities in your project.
On a side note, the Symfony2 team is working on simplifying the configuration and I think there is now an easier way to configure the Doctrine parameters. The sample I propose you is the one I am using right now with the Beta1 of Symfony2.
And finally to answer your question, I think the best is to let Symfony2 deals with the creation and update the database structure. One argument in favor of this would be that you don't need to maintain an SQL file dealing with the database structure. This information is implicitely held by the annotations in your entity so you just have to change you annotations and call the doctrine:schema:update --force command to update the structure. With this in mind, you should not create the structure before hand but let Symfony2 create it for you.
Here's the workflow to test that everything is working:
Update your config.yml (in app/config) to include Doctrine configuration parameters
Open a prompt and go to the root folder of the Symfony distribution (where you see the app, src, vendor and web folders)
Run php app/console doctrine:database:create to create the database in MySQL
Run php app/console doctrine:schema:create to create the database structure
Check in MySQL that the database and the structure have been created correctly
Hope this help.
Regards,
Matt

The original question asked about how to define a non-standard socket in the Symfony2 configuration.
The way I do it is to add a new config setting in app/config/config.yml that pulls in the value from the project parameters file (app/config/parameters.ini).
In app/config/parameters.ini, add a database_socket value:
;[parameters.ini]
database_socket = "/var/mysql/mysql.sock"
and then in app/config/config.yml, pull in the parameter value:
# Doctrine Configuration
doctrine:
dbal:
driver: %database_driver%
host: %database_host%
port: %database_port%
dbname: %database_name%
user: %database_user%
password: %database_password%
unix_socket: %database_socket%
charset: UTF8
That will pass the custom socket path into doctrine's connection.

If using MAMP You can create a symbolic link in your /var/mysql/ folder to /Applications/MAMP/tmp/mysql/mysql.sock file
First check to see if your /var/mysql folder exists if it doesnt make it using:
mkdir /var/mysql
Go to the above folder then write the following to make your symbolic link
sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock mysql.sock
you might also have timezone issues (not related to the above problem but if you're a mamp user you will probably have this one as well) which you can fix by putting the following in your /private/etc/php.ini file (note: this is not your php.ini file found in your MAMP folder)
date.timezone = "America/Montreal"
Note: you might need to change your actual timezone which may not be the same as mine.
References:
http://www.iamseree.com/application-development/doctrine-error-on-mac-osx-it-is-not-safe-to-rely-on-the-systems-timezone-settings-you-are-required-to-use-the-date-timezone-setting-or-the-date_default_timezone_set-function
http://mikecroteau.wordpress.com/2011/08/07/symfony2-could-not-create-database-for-connection-named-sqlstatehy000-2002-no-such-file-or-directory/

Related

Changing the configuration of TF6250-Modbus-TCP when used in TwinCAT/BSD

I have a device running TwinCAT/BSD.
Following section 5 the manual for TwinCAT/BSD I have successfully managed to install the TF6250 package. After updating the firewall rules I have confirmed that I am able connect and issue modbus tcp requests successfully using the Default Configuration from section 4.3 of the TF6250 manual.
My project requires mapping that is different from the default (i.e to the %Q registers rather than %M). Normally (when not not using TwinCAT/BSD) I would be able to edit my mapping via the Modbus TCP Configurator, but there does not appear to be an equivalent tool contained in the package for TwinCAT/BSD.
I have tried copying the mapping files that I would have created in the configurator into the Server directory with no luck. Are you able to tell me how my mapping can be updated in the TwinCAT/BSD environment?
If relevant:
TwinCAT Build: 3.1.4024.19
TC/BSD: 12.2.9.1,2
TF6250-Modbus-TCP: 2.0.1.0_1
pkg repo: https://tcbsd.beckhoff.com/TCBSD/12/stable/packages
I spoke with Beckhoff support who told that TF6250 expects the xml file with the configuration here: /usr/local/etc/TwinCAT/Functions/TF6250-Modbus-TCP/TcModbusSrv.xml
I tested this and it appears to work so all you need to do;
Create the mapping file as per normal (e.g using the windows tool) and copy the file there.
Reboot the device to load the configuration from the file.

Can someone please tell me how to define a check_disk service with check_nrpe in icinga 2?

I'm trying to check disk status of client ubuntu 16.04 instance using icinga2 master server. In here I tried to use nrpe plugin for check disk status. I faced trouble When I'm going to define service in service.conf file. Please, can someone tell me what the correct files that should be changed when using nrpe are. Because I'm new to Icinga and nrpe.
I was able to find the solution to my problem. I hope to put it here because It may help someone's need.
Here I carried check_load example to the explain.
First of all, you need to create .conf file (name: 192.168.30.40-host.conf)regarding the client-server that you are going to monitor using icinga2. It should be placed on /etc/icinga2/conf.d/ folder
/etc/icinga2/conf.d/192.168.30.40-host.conf
object Host "host1" {
import "generic-host"
display_name = "host1"
address = "192.168.30.40"
}
you should create a service file for your client.
/etc/icinga2/conf.d/192.168.30.40-service.conf
object Service "LOAD AVERAGE" {
import "generic-service"
host_name = "host1"
check_command = "nrpe"
vars.nrpe_command = "check_load"
}
This is an important part of the problem. You should add this line to your nrpe.cfg file in Nagios server.
/etc/nagios/nrpe.cfg file
command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 20,15,10
4.make sure to restart icinga2 and Nagios servers after making any change.
You could also use an icinga2 agent instead of nrpe. The agent will be able to receive its configuration from a master or satellite, and perform local checks on the server.

Ansible API : Custom Module

I would like to use a custom module for which I require "hostname" so that I can initiate SSH connection from the custom module and run commands. So I pass transport = "local" to the Runner object. However, I find no way to obtain "hostname" information in the custom module.
I am using Ansible 1.9.2 using Python API.
A module only has the information available that was explicitly passed to it. What you might be interested in instead is an action plugin, which by (non-exisiting) definition runs local on the control machine and has access to more (all?) data.
You can see some action plugin code here: https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/action
PS: Don't you want to upgrade to Ansible 2 before getting started writing custom modules/plugins? The API changed completely and once you upgrade you have to rewrite you module/plugin.
Okay, silly me. It's exactly the same way in the API too. You can extract hostname using {{ inventory_hostname }}.

Archiva ignoring Security.properties

Seems like archiva 2.2 is completely ignoring Security properties
I am following this document:
I have set up the security.properties file under
D:\Apache\Archiva-2.2.0\conf
When I am setting a new password for a user in Archiva UI I am still getting:
You must provide a password containing at least 1 numeric character(s).
security.properties content:
# Security Policies
#security.policy.password.encoder=
security.policy.password.previous.count=9999
security.policy.password.expiration.days=99999
security.policy.password.expiration.enabled=false
security.policy.allowed.login.attempt=3
# Password Rules
security.policy.password.rule.alphanumeric.enabled=false
security.policy.password.rule.alphacount.enabled=false
security.policy.password.rule.alphacount.minimum=0
security.policy.password.rule.characterlength.enabled=true
security.policy.password.rule.characterlength.minimum=3
security.policy.password.rule.characterlength.maximum=0
security.policy.password.rule.musthave.enabled=false
security.policy.password.rule.numericalcount.enabled=false
security.policy.password.rule.numericalcount.minimum=0
security.policy.password.rule.reuse.enabled=false
security.policy.password.rule.nowhitespace.enabled=true
Stop her running and make a backup of your conf/archiva.xml file.
example:
service archiva stop
cp archiva.xml archiva.xml.orig
Edit the config values you want to modify within the main XML configuration file: conf/archiva.xml
Changing the numeric character count:
<numericalcount>
<minimum>0</minimum>
<enabled>false</enabled>
</numericalcount>
Changing the password expiration limit:
<expiration>
<enabled>false</enabled>
<days>999999</days>
</expiration>
These values should already be in your config file (they were in mine). Perhaps they were copied there after my unsuccessful attempts to configure them through the web UI.
Additionally, prevent any user caching behaviour while you're making changes:
<useUsersCache>false</useUsersCache>
Start her up again:
service archiva start
I found a workaround...
stop Archiva
Open the Archiva DB using squirrel sql
Go to SA/JDOUSER table
Column LAST_PASSWORD_CHANGE
Right click to make editable
Modify the value to 10 years from now...
Restart Archiva
Get your 10 years of quiet....

Git - Push to Deploy and Removing Dev Config

So I'm writing a Facebook App using Rails, and hosted on Heroku.
On Heroku, you deploy by pushing your repo to the server.
When I do this, I'd like it to automatically change a few dev settings (facebook secret, for example) to production settings.
What's the best way to do this? Git hook?
There are a couple of common practices to handle this situation if you don't want to use Git hooks or other methods to modify the actual code upon deploy.
Environment Based Configuration
If you don't mind having the production values your configuration settings in your repository, you can make them environment based. I sometimes use something like this:
# config/application.yml
default:
facebook:
app_id: app_id_for_dev_and_test
app_secret: app_secret_for_dev_and_test
api_key: api_key_for_dev_and_test
production:
facebook:
app_id: app_id_for_production
app_secret: app_secret_for_production
api_key: api_key_for_production
# config/initializers/app_config.rb
require 'yaml'
yaml_data = YAML::load(ERB.new(IO.read(File.join(Rails.root, 'config', 'application.yml'))).result)
config = yaml_data["default"]
begin
config.merge! yaml_data[Rails.env]
rescue TypeError
# nothing specified for this environment; do nothing
end
APP_CONFIG = HashWithIndifferentAccess.new(config)
Now you can access the data via, for instance, APP_CONFIG[:facebook][:app_id], and the value will automatically be different based on which environment the application was booted in.
Environment Variables Based Configuration
Another option is to specify production data via environment variables. Heroku allows you to do this via config vars.
Set up your code to use a value based on the environment (maybe with optional defaults):
facebook_app_id = ENV['FB_APP_ID'] || 'some default value'
Create the production config var on Heroku by typing on a console:
heroku config:add FB_APP_ID=the_fb_app_id_to_use
Now ENV['FB_APP_ID'] is the_fb_app_id_to_use on production (Heroku), and 'some default value' in development and test.
The Heroku documentation linked above has some more detailed information on this strategy.
You can explore the idea of a content filter, based on a 'smudge' script executed automatically on checkout.
You would declare:
some (versioned) template files
some value files
a (versioned) smudge script able to recognize its execution environment and generate the necessary (non-versioned) final files from the value files or (for more sensitive information) from other sources external to the Git repo.