If you have a certificate file and private key and need to move that to a Windows server you can easily create a pfx file that can be imported on the Windows server.
Here’s how:
openssl pkcs12 -export -in {cer_filename}.cer -inkey {key_filename}.key -out {pfx_filename}.pfx
You will be asked to provide a password. You’ll need to use this password when you import the certificate on the Windows server.
1. Backup the database
BACKUP DATABASE [database_name] TO DISK = '[backup_filename]'
Make sure the MSSQL has access to write to [backup_filename] Continue reading
1. Install ffmpeg. If you require H.264 or other codecs not available with the Debian provided ffmpeg skip this step and install ffmpeg using this guide: How to install ffmpeg with H.264/MPEG-4 AVC
apt-get install ffmpeg
I’ve had some problems on a Magento installation where all inodes are used up to store the session data. To fix this I had to configure Magento to store the sessions in the database instead of the file system. This is how I didi it:
1. Edit the local.xml configuration file and locate this line: (pico app/etc/local.xml)
<session_save><![CDATA[files]]></session_save>
Here’s how to rebuild indexes:
USE DatabaseName
GO
EXEC sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
GO
EXEC sp_updatestats
GO
This may be useful when doing tests of a web site’s response time. You can add “time” before any command to measure the time it takes.
time wget http://www.aip.im -q --output-document=/dev/null
Results
real 0m0.349s user 0m0.000s sys 0m0.004s
The “real” value indicates the time it took to receive http://www.aip.im.
I’m running Jira behind a Nginx proxy with SSL enabled. Jira was giving me this error message in the login:
We've detected a potential problem with JIRA's Dashboard configuration that your administrator can correct. Click here to learn more
We've detected a potential problem with JIRA's Dashboard configuration that your administrator can correct. Hide
Dashboard Diagnostics: Mismatched URL Scheme
JIRA is reporting that it is using the URL scheme 'http', which does not match the scheme used to run these diagnostics, 'https'. This is known to cause JIRA to construct URLs using an incorrect hostname, which will result in errors in the dashboard, among other issues.
The most common cause of this is the use of a reverse-proxy HTTP(S) server (often Apache or IIS) in front of the application server running JIRA. While this configuration is supported, some additional setup might be necessary in order to ensure that JIRA detects the correct scheme.
The following articles describe the issue and the steps you should take to ensure that your web server and app server are configured correctly:
Gadgets do not display correctly after upgrade to JIRA 4.0
Integrating JIRA with Apache
Integrating JIRA with Apache using SSL
If you believe this diagnosis is in error, or you have any other questions, please contact Atlassian Support.
Detailed Error
com.atlassian.gadgets.dashboard.internal.diagnostics.UrlSchemeMismatchException: Detected URL scheme, 'http', does not match expected scheme 'https'
To solve it you need to edit the server.xml config file located in the Jira “installation directory”, by default: /usr/local/atlassian/jira.
Open the config file with a text editor and add these three lines in the Connector node (pico /usr/local/atlassian/jira/conf/server.xml):
...
<Service name="Catalina">
<Connector port="8103"
maxThreads="150"
minSpareThreads="25"
maxSpareThreads="75"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
<!-- Lines added to solve the URL scheme mismatch -->
scheme="https"
proxyName="example.org"
proxyPort="443"
/>
...
Replace proxyName and proxyPort with the hostname and port of your reverse proxy.
Sometimes you may have a MAC address but need to figure out the IP address. If you have access to a computer on the same network you may be able to look it up using the arp command (works on both Windows and Linux):
arp -a
SSL v2 is weak and outdated protocol. All modern browsers and applications support SSL v3 and that’s why you should disable SSL v2 where possible.
Using this command you can check if SSL v2 is enabled:
openssl s_client -connect www.example.org:443 -ssl2
SSL v2 is weak and outdated protocol. All modern browsers support SSL v3 and it’s enabled by default on Windows 2008 (IIS 7 / IIS 7.5). To make sure all clients are using SSL v3 we must disable SSL v2. This is required for PCI compliance. Continue reading