After comparing several book-keeping solutions (see Comparison of accounting software) I decided to go with FrontAccounting. This would be a fitting choice for me because it's PHP based and this would make any future integration with existing software (also PHP based) easier. It also appeared to have a nice up-to-date interface.
Here are some notes of things I found were left out of the installation procedures/manuals, at least for version 2.3.7.
- Install requirements page will give this bogus error about a 'config_db.php' file not being writable. What it's really trying to say is that it cannot create the file because it doens't have write access to the root FrontAccounting directory. For the sake of installation, give the directory that you're running FrontAccounting from full r/w access (777).
- Install requirements page mentions that directory '../company/0' needs to be writable but forgets to mention the 'company' directory itself also need to be writable if you plan on adding any more than 1 company. If you forget to do this, FrontAccounting will allow you to add additional companies anyways but then you'll get strange behaviour and won't be able to delete them.
- If your using the latest release of MySQL, all the .sql script files under the 'sql' directory will need to be updated. Replace all 'TYPE' occurrences with 'ENGINE'.
- To set desired currency, remember to set under Setup>Company Setup>Home Currency as well as for each applicable bank account under Banking & GL>Bank Accounts. You must set the currency for the bank account before any transaction is created that relates to it, otherwise FrontAccounting will not let you change the currency, even if you delete relevant entries. So be sure to set the proper currency for each bank account before making any journal/GL entries.
- When adding a new company, remember to assign a new script password even though it's optional. I found that if I didn't do this the results were unexpected. In my case, the password for the demo user of the demo company was assigned, even though I would have expected the existing admin password to be used.
- Keep in mind that certain admin features available under setup (such as create new company, system diagnostics, etc.) are only available if logged in as the admin to the first company that was created. In my case, that was the demo company.
- If you are installing extensions (Setup>Install/Activate Extensions), remember to activate any applicable access afterwards under Setup>Access Setup or you won't be able to access the installed extension. Additionally, you must do this for each user in each company that should be able to access the extension. At least this was the case for me for the "Import CSV Items" extension.
Here are some other non-setup related tips I found helpful:
- If you need to edit transactions from a year other than the current, you can set the active year under Setup>Company Setup>Fiscal Year.
Wednesday, September 28, 2011
Conclusion to Strange Hard Drive Behaviour on MBP
Looks like issues described in my previous post (Strange Hard Drive Behaviour On MacBook Pro), regarding plenty of intermittent hangs and beach-balls on a MacBook Pro (MBP) with OX Snow Leopard, can all be blamed on the hard drive. Despite the 'rebirth' I experienced with it, it ultimately just deteriorated again over a relatively short amount of time (about 2 weeks), eventually rendering the MBP once again useless.
I've had a hard drives fail on me before and have known of plenty others, but this is the first one I've come across one that still functions, but has some sort of major handicap. In fact, I still use it externally to successfully backup the MBP, it just takes a lot longer than it should.
So despite symptoms that closely resembled issues described in the threads noted below. My issue was not solved by any amount of software updating or O/S reinstalling.
Random freezing from Snow Leopard - total lock-up for about 30 seconds
INSERT-HANG-DETECTED: System Freezes in Snow Leopard and Leopard
I've had a hard drives fail on me before and have known of plenty others, but this is the first one I've come across one that still functions, but has some sort of major handicap. In fact, I still use it externally to successfully backup the MBP, it just takes a lot longer than it should.
So despite symptoms that closely resembled issues described in the threads noted below. My issue was not solved by any amount of software updating or O/S reinstalling.
Random freezing from Snow Leopard - total lock-up for about 30 seconds
INSERT-HANG-DETECTED: System Freezes in Snow Leopard and Leopard
Thursday, September 15, 2011
Macs: Allowing users of the same group to edit your files
See: Mac OS X Server v10.5, 10.6: Setting a custom umask
This is how I like the Mac setup because the MBP I use has two accounts, both of admin level. W/o this change, the other user can't do anything to files you've created, even if they are shared with you. Incase that article ever goes away, here's the important part of it:
Umask for user applications
In Mac OS X v10.5.3 and later, you can create the file /etc/launchd-user.conf with the contents "umask nnn". Do not include the quotation marks and replace nnn with the desired umask value, such as 027 or 002.
This will set the user's umask for all applications they launch, such as Finder, TextEdit, or Final Cut Pro, and control the permissions set on new files created by any of these applications.
Umask for system processes
In Mac OS X v10.4 and later, create the file /etc/launchd.conf with the contents "umask nnn". Do not include the quotation marks and replace nnn with the desired umask value, such as 027 or 002.
This will set the umask for all processes. Changing this value is strongly discouraged because it changes the permissions on files used by the system software. If the permissions are too restrictive, dependent software may not work. If the permissions are too open, they may introduce security issues.
This is how I like the Mac setup because the MBP I use has two accounts, both of admin level. W/o this change, the other user can't do anything to files you've created, even if they are shared with you. Incase that article ever goes away, here's the important part of it:
Umask for user applications
In Mac OS X v10.5.3 and later, you can create the file /etc/launchd-user.conf with the contents "umask nnn". Do not include the quotation marks and replace nnn with the desired umask value, such as 027 or 002.
This will set the user's umask for all applications they launch, such as Finder, TextEdit, or Final Cut Pro, and control the permissions set on new files created by any of these applications.
Umask for system processes
In Mac OS X v10.4 and later, create the file /etc/launchd.conf with the contents "umask nnn". Do not include the quotation marks and replace nnn with the desired umask value, such as 027 or 002.
This will set the umask for all processes. Changing this value is strongly discouraged because it changes the permissions on files used by the system software. If the permissions are too restrictive, dependent software may not work. If the permissions are too open, they may introduce security issues.
Monday, September 5, 2011
Strange Hard Drive Behaviour On MacBook Pro
Experienced some strange and, thus far, inexplicable behaviour between a MacBook Pro and its hard drive. The Mac would intermittently go off into lah-lah land, allowing the user to do nothing more than move the mouse cursor that had turned into the typical spinning kaleidoscope. It was like the Mac entered a temporary coma upon random user interaction like opening a folder, starting an app, browsing the internet... pretty much anything could trigger it. However the length of time that the Mac remained in the coma seemed to increase with each occurrence, sometimes taking 5+ minutes to wake up. Eventually, it would just stay in this coma state requiring a forced restart. Note that during each coma minimal life could be detected (mouse still moves, some mouse-overs still work, menus may still drop-down) and I could always put my ear to the laptop and hear the hard drive clicking away like mad in search of something it never seemed to find.
At first, forced shut-downs resulted in the Mac taking 20-30 minutes to boot up again. But eventually each forced shut-down resulted in the Mac "loosing track" of the hard drive. Booting up the Mac in Verbose mode yielded various complaints all related to issues with the hard drive (could not find it, I/O errors, time-outs, etc...) and eventually the screen would just continuously roll-over with error messages. If not in Verbose mode you'd miss out on all this fun and be left staring at an Apple logo slowly burning itself into your LCD.
Sometimes, enough forced restarts would get the Mac to boot again (albeit 30 minutes later), but most times required a boot from the system disk, followed by a so-called 'successful' disk repair, followed by another 30 minutes of boot up, followed by more random comas, followed by another forced shut down,... and so the cycle continued until even a boot from the system disk could do nothing. Why? Because at that point the Mac could no longer even mount the drive! (Note: in case you're wondering, I wasn't continuing the cycle just for fun but, rather, with each attempt trying to recover data from the drive before it's suspected death). Now, with the Mac not even finding the drive, I assumed it dead... Wrong!
Now things get interesting. A scheduled trip to a Mac 'genius' at the local Mac store resulted in the 'genius' proclaiming my hard drive dead and suggest I buy a new one off the internet. Ok, I'm cool with that, but I still want to know WHY the stupid thing died after just 1-1/2 years. Thankfully the 'genius' said getting to the drive was easy as cheese and instructed me to just take out the screws on the bottom. Right on, let see what's in this baby! So I took the drive out and popped in another to see if I could isolate the issue. As suspected, the Mac finds the new drive w/o issues and I'm even able to re-install OS X and go on about life as usual. But, I decide not to do that. Wanting to know why the drive died I do a little more poking around and find that with a USB-SATA cable, my WinXP laptop can detect it just fine. Unfortunately, due to the Mac format, i can't actually read it and recover anymore data. If I do the same on the Mac (plug it in over USB), it fails to mount. So I figure, since my WinXP machine can at least detect it, I'll run some tests.
First I do the obvious thing and consult the mfr of the drive, Hitachi, for a drive test. Man, that was a bad idea! Their drive test, called Drive Fitness test (DFT), which you place on a boot-up disk, first failed to do anything other than spin the CD-ROM drive. After much wasted time troubleshooting, I eventually burned the supplied ISO again to find it now works... kind of. It works on my old WinXP box but requires the drive to be internal and my old WinXP box doesn't support SATA. So I try the boot disk on both the Mac and a newer WinXP box. With both the new machines I just get a bunch of HIMEN/XMS errors, blah blah blah more errors, and it dies. Many minutes more wasting time troubleshooting and still no go. WTF Hitachi! So then I go to the Seagate website and download their SeaTools boot-up ISO, also for testing drives. This time it works fine, on all machines. Thanks Seagate! So I run the boot disk on the newer WinXP box but the Seatools 'short' test says the drive is fine. So I install the drive back in the Mac just to double-check and... no dice. Ok, so let's try the 'long' test. This one really is long. A good 3 hours later, the result is a big fat PASS. Well, some suggestions I came across on the web say that some issues may only be detected by mfr software. Except in this case the mfr s/w doesn't do diddly squat! Again, WTF Hitachi! Ok, so for some reason I decide to try the same long test with the drive installed in the Mac. So I remove the other drive (with the new OS X install) and put the original drive back in, forget to boot up off the disk, and the Mac starts up fine (yes, on the F'd up hard drive) as if nothing ever happened. Ok, I'll say it again, WTF!
So, somehow a 'long' test (which explicitly states it doesn't affect drive data) using Seagate s/w on a Hitachi drive somehow cured the drive. Well, I doubt that, but here's my theory. I think the Mac got into some buggy state that was "not happy" with the drive. Maybe some stored RAM parameters (PRAM/NVRAM) were causing the issue. I learned later that these can be reset, but too late to try now. The drive at hand uses the relatively new "GPT Protected" partition format so maybe there's still some bugs to iron out in the interface between OS X and this partition type. In any case, I'm convinced the state of the drive never changed but the state of Mac easily could have during use with the temporarily installed drive with newly installed OS X. The fact that the problematic drive started to work again after the long test is surely just coincidence.
PS. Part of why I'm going on and on and on about this (sorry about the length) is that I've heard multiple other cases where MacBook owners have had their hard drives declared dead long before their expected life. Maybe some of these people replaced a perfectly good drive! If you end up in this situation, maybe this blog will save your ass. Or rather, your hard drives ass.
At first, forced shut-downs resulted in the Mac taking 20-30 minutes to boot up again. But eventually each forced shut-down resulted in the Mac "loosing track" of the hard drive. Booting up the Mac in Verbose mode yielded various complaints all related to issues with the hard drive (could not find it, I/O errors, time-outs, etc...) and eventually the screen would just continuously roll-over with error messages. If not in Verbose mode you'd miss out on all this fun and be left staring at an Apple logo slowly burning itself into your LCD.
Sometimes, enough forced restarts would get the Mac to boot again (albeit 30 minutes later), but most times required a boot from the system disk, followed by a so-called 'successful' disk repair, followed by another 30 minutes of boot up, followed by more random comas, followed by another forced shut down,... and so the cycle continued until even a boot from the system disk could do nothing. Why? Because at that point the Mac could no longer even mount the drive! (Note: in case you're wondering, I wasn't continuing the cycle just for fun but, rather, with each attempt trying to recover data from the drive before it's suspected death). Now, with the Mac not even finding the drive, I assumed it dead... Wrong!
Now things get interesting. A scheduled trip to a Mac 'genius' at the local Mac store resulted in the 'genius' proclaiming my hard drive dead and suggest I buy a new one off the internet. Ok, I'm cool with that, but I still want to know WHY the stupid thing died after just 1-1/2 years. Thankfully the 'genius' said getting to the drive was easy as cheese and instructed me to just take out the screws on the bottom. Right on, let see what's in this baby! So I took the drive out and popped in another to see if I could isolate the issue. As suspected, the Mac finds the new drive w/o issues and I'm even able to re-install OS X and go on about life as usual. But, I decide not to do that. Wanting to know why the drive died I do a little more poking around and find that with a USB-SATA cable, my WinXP laptop can detect it just fine. Unfortunately, due to the Mac format, i can't actually read it and recover anymore data. If I do the same on the Mac (plug it in over USB), it fails to mount. So I figure, since my WinXP machine can at least detect it, I'll run some tests.
First I do the obvious thing and consult the mfr of the drive, Hitachi, for a drive test. Man, that was a bad idea! Their drive test, called Drive Fitness test (DFT), which you place on a boot-up disk, first failed to do anything other than spin the CD-ROM drive. After much wasted time troubleshooting, I eventually burned the supplied ISO again to find it now works... kind of. It works on my old WinXP box but requires the drive to be internal and my old WinXP box doesn't support SATA. So I try the boot disk on both the Mac and a newer WinXP box. With both the new machines I just get a bunch of HIMEN/XMS errors, blah blah blah more errors, and it dies. Many minutes more wasting time troubleshooting and still no go. WTF Hitachi! So then I go to the Seagate website and download their SeaTools boot-up ISO, also for testing drives. This time it works fine, on all machines. Thanks Seagate! So I run the boot disk on the newer WinXP box but the Seatools 'short' test says the drive is fine. So I install the drive back in the Mac just to double-check and... no dice. Ok, so let's try the 'long' test. This one really is long. A good 3 hours later, the result is a big fat PASS. Well, some suggestions I came across on the web say that some issues may only be detected by mfr software. Except in this case the mfr s/w doesn't do diddly squat! Again, WTF Hitachi! Ok, so for some reason I decide to try the same long test with the drive installed in the Mac. So I remove the other drive (with the new OS X install) and put the original drive back in, forget to boot up off the disk, and the Mac starts up fine (yes, on the F'd up hard drive) as if nothing ever happened. Ok, I'll say it again, WTF!
So, somehow a 'long' test (which explicitly states it doesn't affect drive data) using Seagate s/w on a Hitachi drive somehow cured the drive. Well, I doubt that, but here's my theory. I think the Mac got into some buggy state that was "not happy" with the drive. Maybe some stored RAM parameters (PRAM/NVRAM) were causing the issue. I learned later that these can be reset, but too late to try now. The drive at hand uses the relatively new "GPT Protected" partition format so maybe there's still some bugs to iron out in the interface between OS X and this partition type. In any case, I'm convinced the state of the drive never changed but the state of Mac easily could have during use with the temporarily installed drive with newly installed OS X. The fact that the problematic drive started to work again after the long test is surely just coincidence.
PS. Part of why I'm going on and on and on about this (sorry about the length) is that I've heard multiple other cases where MacBook owners have had their hard drives declared dead long before their expected life. Maybe some of these people replaced a perfectly good drive! If you end up in this situation, maybe this blog will save your ass. Or rather, your hard drives ass.
Subscribe to:
Posts (Atom)