Download latest Open Source version from: http://www.sugarforge.org/, then install it:
chown -R www-data:www-data SugarCE-Full-5.2.0c/
ln -s SugarCE-Full-5.2.0c/ sugarcrm
(Installation docs can be found at https://www.sugarcrm.com/crm/support/documentation.)
Now invoke the installation wizard by pointing your browser at install.php, for instance:
and step through to the "Custom Install" point where the database is setup.
Database Name: apps_sugarcrm
Host Name: localhost
Database Administrator Username: root
Database Admin Password: mysql root password
Sugar Database Username: apps_sugarcrm
Sugar Database User Password: vsc apps mysql password
Next screen is "Site Configuration": select a meaningful unique System Name, and record the admin password.
Amazon "Compute Cloud" services are setup such that storage for a running server is kept on an EBS ("Elastic Block Storage") volume mounted on the server. Long-term, offsite (geographic redundancy across multiple data centers) storage is kept in S3. There is a function to snapshot an EBS volume into S3.
List the volumes associated with your account:
This will also show what volumes are mounted on which servers. Stop the services running on the server that might be writing to the EBS (databases in particular, if you wish to have a usable backup):
/etc/init.d/apache2 stopCreate a snapshot:
ec2-create-snapshot vol-3159bd58Check status of snapshot:
SNAPSHOT snap-e309e38a vol-3159bd58 completed
To restore file(s) from one of the backup snapshots, simply create a new volume from the chosen snapshot. Attach it to instance of your running server. Mount the volume temporarily on the server and grab your files. Then unmount the volume, detach it, and delete it. A process that takes only a couple minutes, especially if you use the extremely convenient Firefox ElasticFox plugin.
Git is a program used for distributed Source Code Management (SCM) whose popularity is increasing rapidly. Git seems to be becoming the de facto standard among Debian people, for instance. The first link is to kernel.org, the home of the Linux kernel, because Git was originally created by Linus Torvalds for the Linux kernel development.
Install git command line tools (Debian and derivatives):
apt-get install git-core
(Note that there is a legacy "git" package which has nothing to do with "git" the SCM software....)
You only need to know a few simple command lines to get an astonishing amount of function out of git, and therefore git can be usefully applied to even simple scenarios like bug fixing someone else's software and submitting patches upstream. This last is the example I will work through and demonstrate here, while trying to be more verbose then  & .
First, download and unpack your source code. Then cd into the base directory of the source code, and initialize git by running the following:
This will create a .git subdirectory which will contain git's repository (starting point plus history of changes you make to the code). Now if you do
you will see a long list of "Untracked files", ie. the repository is currently empty. Lets add everything you just unpacked to the repository:
Note the "." after "git add". Its the "." that specifies "everything" under the current directory. "git commit" will prompt you for a commit message, just type "Initial commit" and exit the editor. If you check the status again with "git status" you should see zero untracked changes. Now type
and you will see the record of your initial commit. Now build your unmodified source code (Debian?) just to make sure there is nothing wrong with it.
After the build successfully completes, "git status" will show a long list of changes even though you made no change to the source. Time to introduce .gitignore. Create a (hidden) file called ".gitignore" in your source directory root, and place the following on the first line: "*.o". If you run "git status" again you will discover that all *.o (object files) have vanished from the listing. The object of using .gitignore is to get rid / not track all the build noise, and *.o files definitely qualify. I am going to submit patches upstream, so I am pretty sure the contents of the debian directory are not something I want to track, and have also added a "debian*" line to .gitignore.
Now "git add ." and "git commit" again to get a clean git slate before beginning to make source changes.
Make your first source changes ("git status" should list the changed files). Build, install, and test the software. Let's say this was a partial change that solves part of the problem, but not the whole problem. This probably qualifies for another commit. "git add" the changed files, then "git commit". You can make several change / test / commit iterations, so that "git log" provides a detailed account of what you did. If they do not conflict with other commits, any individual commit can also be backed out.
Should you ever mess up and want to restore your last commit:
should do the trick, and wipe out all changes since the last commit.
When it comes time to submit your patch upstream, git can also generate the patch for you:
will generate a diff between your very last commit, and the one that preceded it.
(Godaddy Incident ID #5828327, should anyone care....)
I do not host any sites at Godaddy, but for quite some time now I have used them as a Domain registrar and sometimes DNS service.
"Sometimes" DNS because I have had more then one occasion to conclude their DNS does not work very well, particularly the domain forwarding. The most recent evidence is a sub-domain that is forwarded to the same server as the domain and another sub-domain. The domain and the other sub-domain work perfectly. For no apparent reason this latest sub-domain "sorta" works: depending on where in the world you are located, you might see the website, or you might get a timeout. When presented with traceroutes from multiple locations, even within the USA, that do timeout, Godaddy technical support drags its feet and repeats, and I paraphrase: "everything works on our network, the rest of the world is broken, go fix the rest of the world".
I conclude that Godaddy does not make much money from customers that only use their domain registration service, and they do not really care very much whether their DNS works for sites hosted elsewhere. Perhaps it is even deliberately broken? It is a wee bit suspicious and improbable that forwarding the main domain and the first sub-domain just works, and all other sub-domains thereafter seem to be subtly sabotaged.
Godaddy tech support do respond to their e-mails in a timely manner, I will give them that. But at this point I would emphatically *not* recommend them as a registrar, or much else, for that matter. There are too many other options out there, and some of them are considerable cheaper, too.
Turn on the SSL module:
cd /etc/apache2/mods-enabled/ ln -s ../mods-available/ssl.conf . ln -s ../mods-available/ssl.load . /etc/init.d/apache2 restart
In Debian, /etc/apache2/mods-enabled/ports.conf should already have logic to listen on the default port 443 if the SSL module is loaded.
Now create a self-signed certificate (tinyca is a nice simple GUI that will do the job....) Just enter minimal information, and export the newly generated cert and key to files, being careful to set the expiration date nice and long, and export the key WITHOUT a password (otherwise you will have to provide a password every time apache is restarted).
Copy the exported certificate files to your server, into directory /etc/apache2/ssl. Now create an SSL block in the Apache Virtual Host where you would like SSL. The *:80 block will respond to normal http requests, and the *:443 block will respond to https (SSL) requests:
DocumentRoot /var/www/webroot ServerName subdomain.domain.com ServerAlias subdomain.domain.com ServerAdmin email@example.com CustomLog /var/log/apache2/access.log combinedNameVirtualHost *:443 DocumentRoot /var/www/webroot ServerName subdomain.domain.com ServerAlias subdomain.domain.com ServerAdmin firstname.lastname@example.org CustomLog /var/log/apache2/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/cert.pem SSLCertificateKeyFile /etc/apache2/ssl/key.pem
I am not sure why the 443 block requires a NameVirtualHost line and the 80 block does not. Interestingly enough, this says "Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol", which might have something to do with it? But despite this I currently HAVE got name-based virtual hosting working on SSL, unless there is something I do not understand here.
Here is a useful reference, in addition to the installed apache docs.
Among SpiderOak's other charms is the capacity for sharing large files. All that is required is, in the SpiderOak client, to create a special link that points to the files that you are offering for download, and then send that link to file recipients.
The Big Send is another service that may be simpler and quicker (requiring neither account creation nor the download of software) for sending files that are less then 100M.
March 2009: location and contents of the $HOME config file have changed. Awesome now looks in ~/.config/awesome/rc.lua instead of ~/.awesomerc, and very little of the documentation seems to reflect this fact. On the bright side, for those of us who do not have a "Windows" key, it is now much easier to reassign the "Default modkey" to something else. To do so, make a local copy of config file:
cp /etc/xdg/awesome/rc.lua ~/.config/awesome/rc.lua
Then edit ~/.config/awesome/rc.lua:
modkey = "Mod1"
Mod1 is the Alt key, which is what you now must use for almost all keyboard shortcuts.
As of early 2009, Awesome upgrades over-write /usr/share/xsessions/awesome.desktop without asking, causing my status bar clock to disappear and my screen locker to not get started. Keep a backup copy and manually restore this file after each upgrade.
It would seem I have discovered a hole in the Linux OS: there is no generalized method for autostarting applications upon login. KDE and Gnome each have their own, and if you use one of the other window managers some have something built-in, others (awesome?) apparently do not.
This is my latest attempt to get a screen locker (xautolock / xtrlock) and a status bar clock going in my setup, borrowed from here. In ~/.xinitrc I have put the following:
#!/bin/sh ~/bin/better-awesome-clock & xautolock -time 10 -locker xtrlock -corners 00+0 -cornerdelay 0 & exec /usr/bin/awesome
And I have modified /usr/share/xsessions/awesome.desktop as follows, such that the "Exec" line invokes .xinitrc rather then invoking awesome directly:
And finally, for the record, this is the contents of ~/bin/better-awesome-clock (borrowed from where I do not recall):
[Desktop Entry] Encoding=UTF-8 Name=Awesome Comment=Awesome window manager Exec=/home/userid/.xinitrc Icon=awesome.xpm Type=Application
#!/bin/sh # while true do if [ -S ~/.awesome_ctl.0 ]; then while true do # See 'man date' to see the possible replacements for the % fields. echo "0 widget_tell mystatusbar clock text " " `date +\"%a, %b %d %I:%M %p\"`" echo "" # an empty line flushes data inside awesome sleep 1 done | awesome-client else sleep 1 fi done
This is, I think, an excellent and concise summary of PHP coding conventions, both for readability and for reducing load on the server. This is the first time I have heard of the advisability of avoiding double quotes, for instance.