FATAL: invalid value for parameter “TimeZone”: “America/Los_Angeles” with DBeaver

I got that message when trying to use DBeaver to connect to a PostgreSQL DB.

FATAL: invalid value for parameter "TimeZone": "America/Los_Angeles"

I found the fix here. The first thing to check is the timezone you have set on the Postgres db itself. You can do this by running “SELECT * FROM pg_timezone_names;”.

Here’s an example:

avenger_agent_prod=# SELECT * FROM pg_timezone_names;
name | abbrev | utc_offset | is_dst
------+--------+------------+--------
UTC | UTC | 00:00:00 | f
(1 row)

The fix is to make a small change the dbeaver.ini file in DBeaver root directory. If you installed this on a Mac, the file is in /Applications/DBeaver.app/Contents/Eclipse/

Just add:

-Duser.timezone=UTC
-startup
plugins/org.eclipse.equinox.launcher_1.4.0.v20161219-1356.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.551.v20171108-1834
-showsplash
# START: change jre version, not using the one in %JAVA_HOME%
-vm 
D:\ArPortable\Java\jdk1.8.0_171\jre\bin\server\jvm.dll
# END
# JVM settings
-vmargs
-XX:+IgnoreUnrecognizedVMOptions
--add-modules=ALL-SYSTEM
-Xms64m
-Xmx1024m
# time zone
-Duser.timezone=UTC
# language
-Duser.language=en

When you restart DBeaver, it should connect.

WordPress stuck on “Briefly Unavailable for Scheduled Maintenance”

This was interesting …

Logged into WordPress and found that I had a few plugins that could be upgraded. I clicked to “upgrade all” and clicked away like I normally do – it usually just finishes upgrading with no big deal. Unfortunately, this time, it got stuck. It said “Briefly unavailable for scheduled maintenance. Check back in a minute.” Well, after about 10 minutes, I got a little impatient and hit google.

Turned out that when upgrading, WordPress creates a file called .maintenance at the root level of your install (in the directory containing wp-admin).

If you take a look at what’s in the file, it looks like this:

cat .maintenance 
<?php $upgrading = 1377922367; ?>

It’s probably safe to just delete the file, but I thought I would rename it just in case I might need it. I renamed it and the blog came back and it appeared that the updates completed too. After doing that however, I renamed it back and it didn’t do anything. Kind of strange, but looks like I don’t have a problem, so I’m happy with it.

SQL 2005 setup notes for VirtualCenter 2.5

create user:
http://msdn2.microsoft.com/en-us/library/aa337562.aspx
(add sysadmin under security)
as stated here: http://kb.vmware.com/kb/1003346

create db and make the user the owner
consideration on recovery mode of DB: http://kb.vmware.com/kb/1001046
how to make changes: http://msdn2.microsoft.com/en-us/library/ms190203.aspx

install native client on VC server
http://www.microsoft.com/downloads/deta … n#filelist
http://download.microsoft.com/download/ … qlncli.msi

When creating ODBC connection, if you get “Not associated with a trusted SQL Server connection”, change authentication mode
http://support.microsoft.com/kb/889615

Other SQL links:
http://support.microsoft.com/kb/889615

http://msdn2.microsoft.com/en-us/library/aa337562.aspx
(add sysadmin under security)
as stated here: http://kb.vmware.com/kb/1003346

create db and make the user the owner
consideration on recovery mode of DB: http://kb.vmware.com/kb/1001046
how to make changes: http://msdn2.microsoft.com/en-us/library/ms190203.aspx

install native client on VC server
http://www.microsoft.com/downloads/deta … n#filelist
http://download.microsoft.com/download/ … qlncli.msi

When creating ODBC connection, if you get “Not associated with a trusted SQL Server connection”, change authentication mode
http://support.microsoft.com/kb/889615

Other SQL links:
http://support.microsoft.com/kb/889615]]–>

Zimbra – postfix transport

Instead of using the /etc/postfix/transport flat file for routing, Zimbra allows you to set this via the command line:
./zmprov cd excite.com zimbraMailTransport smtp:xmxatip.excite.com zimbraDomainType transport

In this case here, the mail domain we’re changing the MTA to is xmxatip.excite.com and the domain is excite.com so that all email to excite.com will go to xmxatip.excite.com.

What changed on the back end is that there’s an entry written to the ldap server:
# excite.com
dn: dc=excite,dc=com
zimbraMailStatus: enabled
zimbraId: 50243e3e-2435-4366-8c18-33697b15f136
dc: excite
zimbraDomainName: excite.com
zimbraDomainType: transport
zimbraMailTransport: smtp:xmxatip.excite.com
objectClass: dcObject
objectClass: organization
objectClass: zimbraDomain
o: excite.com domain

# people, excite.com
dn: ou=people,dc=excite,dc=com
ou: people
objectClass: organizationalRole
cn: people

mysql commands – create database / set permissions

/usr/bin/mysqladmin -u root password ‘new-password’
/usr/bin/mysqladmin -u root -h chunli.shocknetwork.com password ‘new-password’

mysql -u root -p -e “create database <dbname>”
mysql -u root -p -e “grant all on <dbname>.* to <user>@localhost identified by ‘<password>'”