Check for proper configuration of /var/lib/pgsql/data/pg_hba.conf (see TID about unable to start syncengine).

please check also for
/etc/init.d/vmware-tools-services
that are the start script for the vmware tools from packages.vmware.com

It is very popular to use these, you need the sources and compiler on the production servers
thomas

Done (v167)

Perhaps there is a way we can verify the connector is responding to external requests.

We could check for referenceCount in the targets table and suggest TID 7012163.

Whenever mobility stops, we need to make sure cron is also stopped.
I believe we already use a variable to stop mobility in the script. Just need to make sure the stops include "rccron stop"

When running dsapp with alias "dsapp" if the versions were the same (was comparing to itself) it runs an endless loop, and tells you to type "dsapp" to run the script.

dsapp CLI crontab interrupted by user input when dsapp launches.

Scenario:
dsapp -v -i added to crontab.
dsapp is updated, and has autoUpdate set to true.
crontab launches dsapp -v -i and asks whether to update dsapp and never runs vacuum/reindex, etc.

Resolution:
Solution A - configure CLI options to skip autoUpdate, etc.
Solution B - have a parameter to pass Y always to user prompts... like a --silent switch.
Solution C - reconfigure autoUpdate to not ask about updating, just do it when it is available.

Verify Mobility/WebAdmin certificates are valid.

It was requested that a switch be added to be able to update the app from command line as currently when dsapp updates itself it leaves you at the eContinue function. It would be nice if it updates and then exits the dsapp.sh utility.

What if we just have dsapp exit after update instead of having the eContinue function? Also probably should add the update switch in addition to this change as well.

Essentially, customer is trying to update dsapp first and then run a vacuum and reindex in crontab. So a use-case that needs some reconsidering how to address. Perhaps we can have something more automated...

If the customer uses dsapp to apply an FTF / Patch, we should write to a file in /opt/novell/datasync/tools/dsapp/conf/ called patchlevel.
This patchlevel file will keep track of the patches applied to the server.

This can be helpful for two reasons.

1. We can see if they applied the patch or not.
2. Dsapp will check this file, and will not reapply the patch if already applied.

Group similar menu items into new submenus.

We can do this based on the deviceimages table in the mobility db.

column eclass=Calendar,Email,Folder

PSQL command:
select di.eclass,di.edata,di.eaction,d.identifierstring,d.devicetype,d.description from deviceimages di INNER JOIN devices d ON (di.deviceid = d.deviceid) INNER JOIN users u ON di.userid = u.guid;

Get the data we need:
psql -U datasync_user mobility -c "select u.userid,di.eclass,di.eaction,di.edata,d.identifierstring,d.devicetype,d.description from deviceimages di INNER JOIN devices d ON di.deviceid = d.deviceid INNER JOIN users u ON di.userid = u.guid;" > file

Get the DisplayName xml value for the 4th column:
cat file | awk -F '|' '{ print $4 }' | grep -Po "(?<=)[^<]*(?=)"

How do we replace that column in file with our xml parsing command above.

General health check should make sure the version running was updated with update.sh
Check the update.log to verify it ran a complete update process

Check to see if any users are only in one connector. If so, deliver results of what users and what db they were found in and which they weren't. Then prompt for them to be deleted. Go through systematically and delete from tables properly and clean up attachments.

This is now finished with v167. Needs improvement for checking hostname.dnsdomainname as well. Currently only checks for localhost, 127.0.0.1 if proxy is enabled in conf or found in environment (env). Example logging:
Checking for proxy configuration...
NO_PROXY="localhost, 127.0.0.1, 151.155.215.91"
Invalid configuration of proxy detected.

SOLUTION: See TID 7009730 for proper proxy configuration with Mobility

Failed.

Check to see if the server is vmware. If its vmware, make sure its running.

LG Optimus forwarded messages show encoded message body with attachment

For example, in our /etc/datasync/configengine/configengine.xml the admins dn blocks are before the block.

<ldap>
  <groupContainer>o=tt</groupContainer>
  <secure>true</secure>
  <hostname>ldap.tt.nl</hostname>
  <enabled>true</enabled>
  <admins>
    <dn>cn=admin,o=tt</dn>
    <dn>cn=piet,ou=users,o=tt</dn>
  </admins>
  <userContainer>o=tt</userContainer>
  <login>
    <dn>cn=LDAP_User_Locator,ou=sys,ou=alg,o=tt</dn>
    <protected>1</protected>
    <password>VTJGc2RHVmtYMStkcBLABLABLABLABLABBLABLABLA=</password>
  </login>
  <pollInterval>300</pollInterval>
  <port>636</port>
</ldap>

Check availability and connectivity for device ports, etc.

Are Mobility services running? Are the connectors up and listening? (see checkServices.sh)

Done.

Have version checking be a single separate file instead having to download dsapp.tgz and check the version on launch every time.

Remove gal and galsync from mobility database. Restart mobility to have it rebuilt. We can add this in the database submenu.

A customer reported it not working quite right even after the resolved the folder structure problem. There can be other improvements here as well.

The getLogs function should also grab the .xml files so we can get all needed information.

It should also grab maybe the last archived connector log.. as I've had a case where the active log has nearly nothing in it.

Worth a good check here.

It would be a big improvement to just deal with the most recent 5 archived logs rather than iterating through days and hoping there is one there.

I read somewhere that by default the memory available for maintenance work is extremely low. We should look into increasing it perhaps just before we do a vacuum/reindex, then restart postgresql to get the config file change, then do the vacuum/reindex, and set it back to the default and restarting postgresql again. This could be an amazing performance increase. /var/lib/pgsql/data/postgresql.conf

Conf shows default:

maintenance_work_mem = 16MB

Maybe we could try (or more...):
maintenance_work_mem 64MB

http://www.postgresql.org/docs/9.1/static/runtime-config-resource.html:
Specifies the maximum amount of memory to be used by maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults to 16 megabytes (16MB). Since only one of these operations can be executed at a time by a database session, and an installation normally doesn't have many of them running concurrently, it's safe to set this value significantly larger than work_mem. Larger settings might improve performance for vacuuming and for restoring database dumps.

Note that when autovacuum runs, up to autovacuum_max_workers times this memory may be allocated, so be careful not to set the default value too high.

Worth a shot and some testing..

Get a list of POA's and SOAP Ports, quick verify the port is open and connection wasn't refused.

Should verify all the mobile services are set to 'on'

Checking with recommendations according to number of devices.

Code needs to be cleaned up, and/or re-written

When adding an intermediate, there isn't a "CR LF"

dsUpdate function gets error on line 722 while updating

What do these new states indicate? I think state 11 might be a new init-syncing..

It would be nicer to just decrypt the actual password instead of having to prompt as many customers never remember their passwords. It is nice that there is a function now to recreate a new password. Suggestion came from Ian, who said they might use the hostname somehow when encrypting the password. An idea we can play around with.

Add to health check to verify webadmin certs as well

With new encode / decode, this code should be re-written to decode the admin password if protected is equal to 1

Once decoded simply run the rest of the code WITHOUT user input
DO NOT store this password in a file

Done v167

Finished ghc_checkManualMaintenance (v167). Needs testing..

Verify LDAP connectivity if it has been configured.

With the creation of the decode / encode functions, soapLogin function can now decode the trustedAppKey instead of asking for the trusted app file.

Should be re-written to check if protected or not. If protected is equal to 1 then decode, and store in file for later use.

dsapp ghc should check to make sure users / groups are on both groupwise and mobility connector in targets table.

This would be sweet...

Check to see if user exists only in 1 db and not the other, report information...
Cleanup for this could be kept separate.

Check to see if there are any rpmsave files, means that SLES was updated without Mobility Add-On. Would have to check configengine.conf to see if it has tags, etc.

General HeathCheck would always check if monitor was running. Pre 2.x builds of mobility didn't have monitor.