I think some of you have already figured this but this could also maybe help other people.
To be able to configure your virtual server at OVH in bridge mode you need to comment the "GATEWAYDEV" parameter in '/etc/sysconfig/network' after having followed their guide. Please see this issue number on the bug tracker for more details:
Hi Peter, again thanks for the update, its good to have an idea of when to expect the new release. Are you planning to release some of the 6.x fixes and improvements listed in the roadmap as being complete in the near future? I know in an earlier post you said that much of the development focus was on 7, but hopefully some of the more minor updates (clam AV for example) won't be 'held back'.
Right now, we have an alpha version floating around to bootstrap the development and testing process. We're hoping to have a public beta available in October, but that depends on the following roadblocks:
- The complexity involved for customizing the installer/ISO build process
- Having EPEL for RHEL 7 out of beta, or at least closer to final than right now
- Making sure other upstream vendors (e.g. Zarafa) are either supporting or close to supporting RHEL 7
The good news with the development process is that the code base for ClearOS 6 and 7 will be identical. Yes, a few tweaks are required here and there, but supporting both versions will be trivial for app developers. It also helps that no architectural changes are required for Samba/LDAP, so the hurdles for upgrading 6 to 7 will be much much lower.
Mick Russom wrote: How soon until ClearOS upgrades to a -7- base? This is a big deal as the new kernel is far better - I've done extensive tests and for my purposes this is a huge upgrade.
RHEL 7 does feel a lot snappier, both on real hardware and in VirtualBox! I'll post a ClearOS 7 update in a new thread later today.
Its been such a long time since I've looked at the config, I thought it was 1430, but must have put it lower still subsequently! (some IPS...I remember AOL being particularly bad, and didn't provide a true internet experience, in that there was some form of AOL 'wrapper' around their version of the internet and they required something lower, although I think this has been consigned to the history books and they are the same as everyone else).
For interest, the majority of our sites are on the same ISP (Zen Internet). One of the Sites is on a line supplied by not just a different ISP, but a different telephone network (KC in Hull), their network is completely separate from that of the rest of the UK, and I believe the 1,400 was put in just for them.
no harm in trying a really low figure and working upwards.
I'm sure Nick is correct in suggesting the MTU, you need to factor in the encryption packet header. Most ISP's (and LAN devices) have an MTU of 1500, but if your 'full data' backup packet is this size, the IPSEC header will force it over 1500. The solution is to reduce the MTU to an acceptable level, most chose either 1458 or 1430. I'm running with 1430 across all our VPNs.
That would be a really cool feature to build into the GUI. I think there is an app in the marketplace for time based control, but not to implement a 'scheme' of permitted or denied sites by time.
If your code worked in your previous squid configuration then it should work under clear (although you might need to spend some time working out where all the various 'elements' of the configuration file are now stored!)
does this work from a browser on a pc or laptop configured with an IP on the same range as the phone? This will eliminate the phone, as I think if you have a proxy / port issue it will be evident on a pc too.
What high specification machines your are discussing! I run all of our 150 machines through a dual core 3.0Ghz with 4GB ram, and it seems plenty fast for what we need. The sort of specifications you mention would befit most enterprises, let alone a home setup! are you one of these people with a data-centre in your basement
Yes, it will break Zarafa with the following message:
Not Found: PHP mapi extension not found
If you have upgraded zarafa, please restart Apache
Zarafa WebApp can't start because of incompatible configuration.
Please correct above errors, a good start is by checking your '/etc/php.ini' file.
Or if you wish, you can disable this config check by editing the file '/usr/share/zarafa-webapp/config.php', but this is not recommend.
In my quick tests, it works fine for Joomla!, WordPress and Tiki Wiki CMS Groupware. I didn't try ownCloud but I suspect it works fine as well.