Re: [SOGo] SOGo database
On Tue, 26 Apr 2011, Sven Marth wrote: Hi Sven, you should increase the kernels maximum size of shared memory segment. To do this. edit your /etc/sysctl.conf. For example: kernel.shmmax = 134217728 (sets the value to 128 MB). You can also find a explanation in http://www.postgresql.org/docs/8.4/interactive/kernel-resources.html I use 1 GB (it corresponeds to /proc/sys/kernel/shmmax on Linux) which is the same value which uses Pascal. cat /proc/sys/kernel/shmmax 1342177280 I tried to set more, without success. Thanks, Milos -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo database
Am 26.04.2011 08:05, schrieb Milos Wimmer: > On Tue, 26 Apr 2011, Pascal Gienger wrote: > > Hello Pascal, > >> What's the size/value of >> >> shared_buffers = ... >> and >> max_locks_per_transaction = ... >> >> in your postgresql.conf? > > > shared_buffers = 24MB [default value] > max_locks_per_transaction = 256 [default value = 64] > > > thank, > Milos > Hallo Milos, you should increase the kernels maximum size of shared memory segment. To do this. edit your /etc/sysctl.conf. For example: kernel.shmmax = 134217728 (sets the value to 128 MB). You can also find a explanation in http://www.postgresql.org/docs/8.4/interactive/kernel-resources.html cu Sven -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo database
On Tue, 26 Apr 2011, Pascal Gienger wrote: Hello Pascal, What's the size/value of shared_buffers = ... and max_locks_per_transaction = ... in your postgresql.conf? shared_buffers = 24MB [default value] max_locks_per_transaction = 256 [default value = 64] thank, Milos -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo database
Am 26.04.11 00:17, schrieb Milos Wimmer: On Thu, 21 Apr 2011, Pascal Gienger wrote: We have 60552 tables now, and the WAL backup (hot backup) is still running without any problem. PostgreSQL 8.4.7 on Ubuntu 10.04 LTS Server with different volumes for DB files and for DB log (WAL) files, 1G shared memory. I have 125406 tables now, PostgreSQL 8.4.7. SOGo works without problem with so many tables. But I cannot backup database with pg_dump command. It writes: pg_dump: WARNING: out of shared memory pg_dump: SQL command failed pg_dump: Error message from server: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction. pg_dump: The command was: LOCK TABLE public.sogodrendr0013165525c_quick IN ACCESS SHARE MODE What's the size/value of shared_buffers = ... and max_locks_per_transaction = ... in your postgresql.conf? -- Pascal Gienger Jabber/XMPP/Mail: pascal.gien...@uni-konstanz.de University of Konstanz, IT Services Department ("Rechenzentrum") Electronic Communications and Web Services Building V, Room V404, Phone +49 7531 88 5048, Fax +49 7531 88 3739 -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] BTS activities for Monday, April 25 2011
Title: BTS activities for Monday, April 25 2011 BTS Activities Home page: http://www.sogo.nu/bugs Project: SOGo For the period covering: Monday, April 25 2011 idlast updatestatus (resolution)categorysummary 3 2011-04-25 08:15:32 resolved (fixed) Backend Calendar Feature Request: Ressource Planning 1271 2011-04-25 09:57:36 resolved (fixed) Web Calendar Calendar selection after unsubsribe may lead to errors
Re: [SOGo] SOGo database
On Thu, 21 Apr 2011, Pascal Gienger wrote: We have 60552 tables now, and the WAL backup (hot backup) is still running without any problem. PostgreSQL 8.4.7 on Ubuntu 10.04 LTS Server with different volumes for DB files and for DB log (WAL) files, 1G shared memory. I have 125406 tables now, PostgreSQL 8.4.7. SOGo works without problem with so many tables. But I cannot backup database with pg_dump command. It writes: pg_dump: WARNING: out of shared memory pg_dump: SQL command failed pg_dump: Error message from server: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction. pg_dump: The command was: LOCK TABLE public.sogodrendr0013165525c_quick IN ACCESS SHARE MODE My system has 32 GB RAM, here are my relevant system settings: cat /proc/sys/kernel/shmall 1342177280 cat /proc/sys/kernel/shmmax 1342177280 cat /proc/sys/kernel/sem 250 32000 32 128 Does somebody have any experience how to backup database including thousands of tables with pg_dump command? I'm using sogo-tools for backup now, works nice. Nevertheless - to have complete dump of the database would be fine... Thanks, Milos -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Re: SOGo-Nightlies can't be installed!
On 11-04-20 6:30 PM, Martin Lehmann wrote: What about this bug? It's very easy to fix and until it's fixed the nightlies are unusable for CentOS/Redhat! The nightlies for x86_64 should be working now. The libmemcached-0.44 package was broken since it depended on libmemcached.so.3, this should not happen, it should be self contained... Can you give it a try and see if it works for you? As for the SRPMS, they should now be uploaded to the repo. See: http://inverse.ca/downloads/SOGo/CentOS5/nightly/x86_64/RPMS/ You've only to replace "libmemcached" in libmemcached.spec through "libmemcached3" or sometheing simular for version 0.3 and rebuild the SRPMS. I'd do it myself but the SRPMS for nightlies aren't released. Where can I get them?! Am 17.04.2011 01:24, schrieb Martin Lehmann: Hi, it's impossible to install the SOGo-Nightlies for CentOS from 16-Apr-2011! There's a dependency problem for the libmemcached RPMs. There are 2 versions libmemcached-0.34-1 and libmemcached.0.44-1 and rpm tries to install only the latest what doesn't work as libmemcached.so.3 is also needed! I think you need to create a packaged "libmemcached3" (for version 3) and "libmemcached" (for the new version 4). This way, rpm doesn't try to replace the older libmemcached.so.3 Here's the error output from "yum update": libmemcached-0.44-1.x86_64 from sogo-nightly has depsolving problems --> Missing Dependency: libmemcached.so.3()(64bit) is needed by package libmemcached-0.44-1.x86_64 (sogo-nightly) libmemcached-0.44-1.x86_64 from sogo-nightly has depsolving problems --> Missing Dependency: libmemcached.so.3(libmemcached_3)(64bit) is needed by package libmemcached-0.44-1.x86_64 (sogo-nightly) Error: Missing Dependency: libmemcached.so.3()(64bit) is needed by package libmemcached-0.44-1.x86_64 (sogo-nightly) Error: Missing Dependency: libmemcached.so.3(libmemcached_3)(64bit) is needed by package libmemcached-0.44-1.x86_64 (sogo-nightly) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Regards, Martin P.S.: Where're the nightly SRPMS? I can't find them. I want to build my own version of libmemcached3 until SOGo fixes this error. Thx. -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] ANN: Wiki
Hello everyone, We now have an official Wiki where anyone can write about her/his own experience with SOGo : http://wiki.sogo.nu/ To contribute, you'll need to register (click on "Login"). It's currently empty, ready for your input. On our side (at Inverse), we'll continue to maintain the installation guides and the FAQ on the official website. Thanks! Francis -- flachape...@inverse.ca :: +1.514.755.3640 :: http://www.inverse.ca Inverse :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] Resources planning
Hello, A new feature has just landed in the SOGo code: resources planning. It's now possible to tell SOGo how to identify resources (conference rooms, projectors, etc.) and apply constraints on them to avoid double-bookings and to automatically accept the "invitation" for them. This works right now only over LDAP and you can identify resources using either : a- the "calendarresource" objectClass (see http://tools.ietf.org/html/draft-cal-resource-schema-03) b- a specific LDAP attribute (specified by the "KindFieldName" parameter in your SOGoUserSources) which must hold either "location", "thing" or "group" (also see the URL above) Then, you must also set how many simultaneous bookings are allowed for this resource. A value of "0" means no limit. This limit is also read from a LDAP attribute specified by "MultipleBookingsFieldName". If SOGo can't determine it's a resource, the code will work just like it did before - meaning that someone must accept/decline the invitation for the resource. If it can, the following scenarios are possible: 1- automatically accept the invitation for the resource if there's no conflict 2- prevent save operations if there's a conflict (ie., someone tries to use a resource already scheduled for an other meeting) A SOGoUserSources entry which can handle resources might look like : { CNFieldName = cn; IDFieldName = uid; KindFieldName = description; MultipleBookingsFieldName = multiplebook; UIDFieldName = uid; baseDN = "dc=inverse,dc=ca"; bindDN = "cn=sogo,ou=services,dc=inverse,dc=ca"; bindPassword = zot; canAuthenticate = YES; displayName = "Partag\U00E9"; hostname = "127.0.0.1"; id = public; isAddressBook = YES; port = 389; }, while a resource defined in LDAP *could* look like : dn: uid=room103,ou=resources,dc=inverse,dc=ca objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top uid: room103 mail: room...@inverse.ca cn: room103 sn: room103 multiplebook: 1 description: location Nightly builds are being regenerated and should be available in less than 30 mins with that code in. Regards, -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists