Archivo por meses: febrero 2012

Plesk 10 bugs

Posted on by
Responder

(versión en español)
Recently have been appeared  vulnerabilities in API of Plesk . These vulnerabilities are  SQL injection type and have been a constant worry for more than one.

I leave details in the following link http://kb.parallels.com/en/113321

The latest microupdates of versions 9.5.4 and 10.3.1, fixed such vulnerabilities.

But those who chose to upgrade to 10.3.1 or 10.4.4 have been involved in another mess. These versions of the Plesk panel have another bug, though no worse than the previous one, is quite important.

The problem has to do with php and any change made in the php main configuration file  (/ etc / php.ini usually) not taken into account. So, for example, if we remove the safe_mode (safe_mode = Off) for all domains, if we edit the file / etc / php.ini and we restart the web service for the change to take effect, we will can see that has not happened.

The only thing you can do is manually edit the php.ini file of the domains that you need, which is a bit sloppy but it works.

For now Parallels has provided no solution, or to indicate when it will. To be a product for which a license is paid, is taking too long.

We do not usually so staunchly defend any software, as none is free of bugs, but there are other panels such as ispCP which are free and so far has not been published any vulnerabilities inherent to the panel. Something else, are the vulnerabilities that have appeared in software that goes under the panel, as the web server, kernel, …

 

Django South, listing, merge and fixing several messes

Posted on by
Responder

(versión en español)

In a Django project in which several people working under a repository, it is common you do changes in the database more or less simultaneously and when in “pre” / staging, or worse, directly in production you make the “. / manage.py migrate app” and get the following Traceback, is when you start to get sick.

(the app in this example is called “main”)

Running migrations for main:  ! Migration main:0048_auto__add_field_reseller_cdn_css__add_field_reseller_cdn_js__add_field should not have been applied before main:0047_auto__add_securitylevelfile but was. Traceback (most recent call last):  File "./manage.py", line 11, in <module>  execute_manager(settings)  File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 438, in execute_manager  utility.execute()  File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 379, in execute  self.fetch_command(subcommand).run_from_argv(self.argv)  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 191, in run_from_argv  self.execute(*args, **options.__dict__)  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 220, in execute  output = self.handle(*args, **options)  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/management/commands/migrate.py", line 105, in handle  ignore_ghosts = ignore_ghosts,  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/migration/__init__.py", line 185, in migrate_app  raise exceptions.InconsistentMigrationHistory(problems) south.exceptions.InconsistentMigrationHistory: Inconsistent migration history The following options are available:  --merge: will just attempt the migration ignoring any potential dependency conflicts. aloja:/var/www/virtual/guardatum.com/guardatum_code# ./manage.py migrate 0054 main Traceback (most recent call last):  File "./manage.py", line 11, in <module>  execute_manager(settings)  File "/usr/lib/python2.5/site-packages/django/core/management/__init__.py", line 438, in execute_manager  utility.execute()  File "/usr/lib/python2 achat de viagra quebec.5/site-packages/django/core/management/__init__.py", line 379, in execute  self.fetch_command(subcommand).run_from_argv(self.argv)  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 191, in run_from_argv  self.execute(*args, **options.__dict__)  File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 220, in execute  output = self.handle(*args, **options)  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/management/commands/migrate.py", line 78, in handle  apps = [Migrations(app)]  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/migration/base.py", line 60, in __call__  self.instances[app_label] = super(MigrationsMetaclass, self).__call__(app_label_to_app_module(app_label), **kwds)  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/migration/utils.py", line 41, in app_label_to_app_module  app = models.get_app(app_label)  File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line 140, in get_app  raise ImproperlyConfigured("App with label %s could not be found" % app_label) django.core.exceptions.ImproperlyConfigured: App with label 0054 could not be found

Do not run the “–merge” that is recomended. What you need to do is show a list of historical migrations and see which ones have been left hanging:

( ) 0047_auto__add_securitylevelfile (*) 0048_auto__add_field_reseller_cdn_css__add_field_reseller_cdn_js__add_field (*) 0049_auto__add_field_orders_admin (*) 0050_auto__del_field_orders_admin () 0051_auto__add_field_customer_notify_reseller

As we see the 0047 is that we are breaking consistency. What we do is mark it as already done this migration, since in the past and effectively carry out the 0047;-)

./manage.py migrate main --fake 0047_auto__add_securitylevelfile

We run list to see the result:

./manage.py migrate --list
(*) 0047_auto__add_securitylevelfile
 (*) 0048_auto__add_field_reseller_cdn_css__add_field_reseller_cdn_js__add_field
 (*) 0049_auto__add_field_orders_admin
 (*) 0050_auto__del_field_orders_admin
 () 0051_auto__add_field_customer_notify_reseller

and we run migrate at the end

./manage.py migrate main

You can also go a little further, resetting completely  South