mbenkmann / limux-gosa Goto Github PK

From [email protected] on September 20, 2012 16:36:57

force localboot should cancel softupdate and install jobs (including on other servers via foreign_job_updates)

Original issue: http://code.google.com/p/go-susi/issues/detail?id=10

From [email protected] on November 13, 2012 18:43:54

gosa-si 2.7 (at least the gosa-si-client) attaches its own source to messages as ";IP:PORT". This breaks GosaDecrypt().

• cut off the appendix
• add test case to system test

Original issue: http://code.google.com/p/go-susi/issues/detail?id=23

From [email protected] on November 23, 2012 15:24:06

A typical use case is the following:

1. softupdate/install triggers
2. user is notified that he should log out
3. user selects "shutdown" instead of "logout"

Make sure that in this use case the softupdate/install properly activates. Maybe send regular wake up messages for some time if the softupdate/install doesn't start after the alotted time.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=29

From [email protected] on September 10, 2012 21:09:13

Write an external program that sends via parallel connections a mix of foreign_job_updates and gosa_query_jobdb. The test should fulfill 2 purposes:

• Determine how many requests per second go-susi can process
• Verify proper locking of the jobdb

The test should be able to run against an ordinary gosa-si, too.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=8

From [email protected] on December 21, 2012 15:14:09

Needs a little more work to escape embedded apostrophes in $result and
possibly to cope with missing/empty $result.

Attachment: show-error-result.patch

Original issue: http://code.google.com/p/go-susi/issues/detail?id=35

From [email protected] on November 14, 2012 20:31:53

Currently peers will remain forever in serverdb. Dead peers should be removed from serverdb when the PeerConnection gives up.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=27

From [email protected] on September 10, 2012 20:37:31

Currently go-susi does not support and in the command gosa_query_jobdb.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=7

From [email protected] on September 21, 2012 21:53:55

GOsa can understand certain formats of error replies (see class_gosaSupportDaemon.inc in function _send()). Currently go-susi does not return error replies in that format. This should be changed.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=14

From [email protected] on November 13, 2012 18:45:51

gosa-si-client sends some messages to gosa-si-server and expects some answers even if no jobs are being processed ("here_i_am"). Add minimal support for these to avoid logspam.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=24

From [email protected] on November 13, 2012 18:46:45

information_sharing messages currently cause logspam. Add minimal support.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=25

From [email protected] on September 17, 2012 22:51:12

When go-susi is launched, it loads jobdb.xml to initialize the jobdb (jobdb.go:JobsInit()). This should filter out any jobs from other servers, because those jobs may be already finished. When the newly launched go-susi sends its new_server message to other servers, they will (if they are go-susi and not gosa-si) answer with a copy of their jobdb, so the new go-susi will learn the other server's jobs in this manner.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=9

From [email protected] on September 10, 2012 20:27:42

go-susi --sniff contacts the go-susi instance running on the machine and causes it to send debug level log messages back over the connection. This way go-susi can be running with loglevel 0 but for troubleshooting you can attach to the running instance rather than restarting it with -v (which may cause the problem to disappear)

The command must be encrypted with the ServerPackages key because whoever has that key can decrypt all messages anyway.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=5

From [email protected] on February 14, 2013 18:57:26

Presently, functions like SystemGetState() in db/systemdb.go only read the machine object. These functions need to be extended to read from gosaGroupOfNames that include the machine.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=43

From [email protected] on February 14, 2013 20:35:02

config/config.go needs to set the variables UnitTag and UnitTagFilter

Original issue: http://code.google.com/p/go-susi/issues/detail?id=45

From [email protected] on February 11, 2013 14:53:41

Because of the strange @servers rotation in gosa-si-client, it is better to use proper gosa_ping messages to re-establish/check client connections.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=42

From [email protected] on October 17, 2012 22:13:35

Currently if more than 2s are subtracted from the system clock after a call to JobUpdate(), that job will not be processed until some other call to JobUpdate() occurs after the clock adjustment and schedules a JobHandling() at a later time. This should be made more robust. One idea would be a function

util.SleepUntil(t time.Time)

which unlike time.Sleep() rechecks the actual time when it wakes up and goes to sleep again if the time is not yet reached.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=20

From [email protected] on February 14, 2013 20:21:28

At present, here_i_am.go sends go-susi's LDAP data to the client instead of the data from the gotoLdapServer attribute.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=44

From [email protected] on February 15, 2013 18:11:45

db.ClientWithAddress()

db.ClientUpdate() with case where 2 old entries are replaced (i.e. the new entry has the same as entry 1 and the same as entry 2)

db.SystemGetState(mac,"objectclass") for an object with multiple objectclasses to check that as documented only the 1st object class is returned. I think this is not true ATM. Either change docs or change code to make consistent.

db.SystemDataForMAC()

db.SystemSetState() test case to verify that the new attribute can replace multiple existing attribute values (e.g. gotoNtpServer). To create this test case it will probably be necessary to add a new function db.SystemSetStateMulti() that takes an array of values, so that it can be used to set multiple values before the test.

db.SystemSetState() test case where the attribute to set does not yet exist. This will probably need the db.SystemSetStateMulti() function described in the previous paragraph so that the test can delete the attribute before the test.

Test case for here_i_am with a client that is not in LDAP. Test that go-susi sends registered followed by detect_hardware

Test case for here_i_am with a client that is in LDAP. Test that go-susi sends registered followed by new_ldap_config and new_ntp_config. This should happen even if the client object has neither attribute. The missing LDAP data should be replaced with go-susi's own data and the default NTP server should be pool.ntp.org.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=46

From [email protected] on October 25, 2012 15:54:39

Currently go-susi opens its log file once and keeps it open. This means that logrotate will not work with go-susi's logfile. This should be changed.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=21

From [email protected] on December 10, 2012 21:53:47

There are several ways for jobdb to get broken local jobs, e.g.

1. go-susi is stopped after a job has gone to status "processing" but before it has actually been executed. On restart the job will be restored in status processing but never go to "done".
2. go-susi is stopped (or network is interrupted) while an installation is in progress. The installation completes without telling go-susi.
3. A client crashes during installation because of a hardware defect. The machine is taken out of commission, so that the install job will never resume.

At some point local jobs with a time in the past should be cleaned up.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=34

From [email protected] on September 24, 2012 18:57:19

In the config section [ServerPackages] a key "address" can be used to list servers to communicate with in addition to those listed in DNS. This is already documented in the manual. Implement it.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=16

From [email protected] on September 22, 2012 23:29:37

gosa-si has the problem that if it can't determine the plainname when the job is added, it won't ever be filled in and only the MAC address will show in GOsa. This typically happens when a new machine is activated whose install job triggers before it has created its LDAP object.

go-susi should retry to determine the plainname on certain occasions if only the MAC is known, for instance on CLMSG_* messages generated during the installation.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=15

From [email protected] on November 13, 2012 18:48:08

gosa_update_status_jobdb_entry is currently documented in the manual but not implemented. Implement it.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=26

From [email protected] on February 15, 2013 18:19:58

Currently client_connection.go:tryToSend() does not implement sending messages to clients registered at peer servers. Fix this.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=47

From [email protected] on November 09, 2012 10:51:08

Currently go-susi calls ldap* command line tools with the password as command line parameter (-w password). This exposes the password in ps output. This should be fixed either by accessing LDAP directly or by using the -y option which allows passing the password via a file.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=22

From [email protected] on January 29, 2013 10:05:36

This ticket is from the klax wishlist for BC 5.0

When a client registers itself at go-susi (I think that's the here_i_am message), it should send its actual version (/etc/debian_version or from /etc/sysconfig/GOto, however the latter does not seem to exist on servers) and go-susi should change the faiclass attribute in LDAP if necessary to match that version.

This requires patching gosa-si-client to add the data to its registration message but that should be easy.

ATTENTION! Make sure that this does not happen during reinstallation or softupdate. Checking faistate and only making the change if it is localboot should be enough.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=37

From [email protected] on August 28, 2012 19:59:27

Currently xml_db.go:Persist() calls db.data.Verify() to verify the integrity of the underlying xml.Hash data structure. This check exists as a safety net against bugs the test suite did not find. After some reasonable real-world testing period it can be removed.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=1

From [email protected] on September 20, 2012 16:58:49

On startup go-susi should check if the machine it's running on is listed in DNS and should log a warning if it is not listed.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=13

From [email protected] on February 11, 2013 10:32:11

Test case:

1. register several clients at vts-susi
2. stop vts-susi
3. stop client X and restart it so that registers with a different server
4. start vts-susi
5. Check that vts-susi re-establishes the client connections and sends new_foreign_client messages for all clients that re-register at vts-susi (probably none, because of Issue #39 )
6. Check that after the dust settles all clients (in particular client X) are in clientdb with the proper server(s).

Original issue: http://code.google.com/p/go-susi/issues/detail?id=40

From [email protected] on September 20, 2012 16:43:53

On startup as well as gosa_query_jobdb, LDAP entries for computers should be scanned and for FAIstates other than localboot (including error states) install jobs should be generated if they do not exist in the jobdb. The goal is to make sure that gosa_query_jobdb will always include all machines that are not in localboot state. These generated jobs should have siserver=unknown so that they will not actually cause launching a new install job. However when such a job is deleted, it must cause the FAIstate to be set to localboot and the cancelling of the job must be communicated to other servers.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=11

From [email protected] on November 23, 2012 17:58:04

In order to wake up a machine, go-susi needs to know that machine's network's broadcast address. If the machine's fully qualified name is known, it can be resolved to an IP from which the network is easy to derive. If only the plain name of the machine is known this fails if the machine is on a different subdomain than the server. One way to overcome this is to use the [ServerPackages]/domains config option. However this is not easy to configure automatically.

go-susi should be able to learn about possible networks automatically through the following means:

client addresses from messages like new_server, new_foreign_client as well as communications received from clients are used to get

1. the possible numeric networks
2. by reverse lookup the names of domains

When a machine needs to be woken up, go-susi tries the following

1. try to resolve the cn of the machine (note that this is NOT what db.PlainnameForMAC() returns)
2. try to resolve the plain name (i.e. without a domain if the cn has a domain)
3. try a reverse lookup of ipHostNumber and match that against the plain name. If the reverse lookup yields plain name "." something, then use the ipHostNumber
4. for each of the known domain names, try to look up plain name "." domain.
5. If none of the above yielded an IP address, spam all known numeric networks' broadcast addresses with the WOL packet.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=30

From [email protected] on November 27, 2012 10:25:43

Currently a new goroutine is started for each scheduleProcessPendingActions(). This causes many goroutines to be created and if test jobs in the distant future are created and then cancelled these goroutines stick around. This is not a real problem since Go should be able to have 10000s of goroutines running and all of these goroutines are simply blocking in util.WaitUntil(), so they're not wasting CPU.

However it would be nicer to have only a single goroutine for this. My current idea is the following:

• create a Deque that stores timestamps in sorted order
• scheduleProcessPendingActions adds each new timestamp to the deque via deque.InsertSorted() (to be added to deque). InsertSorted() returns the index where the item was inserted.
• the scheduler goroutine has a timer channel and a signal channel. It waits until either channel receives something. The timer channel is set to the timestamp At(0). If a signal is received on the signal channel (every time scheduleProcessPendingActions() runs it sends on this channel), the scheduler removes the next elements from the queue until At(0) is a time in the future. Then it programs the timer for that timestamp, signals processPendingActions and goes blocking again on the 2 channels.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=32

From [email protected] on August 30, 2012 18:11:28

Fetching LDAP data can take a few seconds. To speed things up for the user, go-susi should prefetch the LDAP data potentially used by GOsa and serve the prefetched data rather than querying LDAP when a GOsa request comes in.

There are 2 competing requirements here:

1. We want to prefetch often, so that the data is as fresh as possible
2. We don't want to put a constant load on the LDAP server

As a compromise, every GOsa request that comes in should start or restart a timer of e.g. 2 minutes. During these 2 minutes go-susi will continuously query the LDAP server for all relevant data as often as is possible for that kind of data (i.e. after every query has completed, the same query is issued again with only a few seconds delay). Once the 2 minutes have elapsed, the fetching stops.

Experiments or logfile statistics should be used to find the shortest period of time that will give the necessary benefits to the user. 2 minutes is probably too long.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=3

From [email protected] on February 18, 2013 19:23:18

GOsa requests multiple things from the si server when the user edits are system. Some of these, such as the log files, are not essential for performing installs. Add dummy answers for those to keep GOsa happy.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=50

From [email protected] on November 25, 2012 16:33:38

Add support for a message

panic that causes a panic().
Possibly distinguish between

panic

and

panic

or something like that. The former case would do panic("foo") and the latter would do panic(nil) (which won't be caught by util.WithPanicHandler)

The application for this function is to get a backtrace of all goroutines in the log file which is useful to debug deadlocks and similar issues.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=31

From [email protected] on November 21, 2012 17:20:07

new_foreign_client is a message that peer siservers send sometimes. To get to a state where go-susi logs no errors when idle, minimal support for this message should be implemented.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=28

From [email protected] on February 15, 2013 18:21:55

Currently messages to clients are not persistent, even if their TTL says that resending should be attempted for days. Add a database so that client messages are not lost even if go-susi is restarted.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=48

From [email protected] on August 30, 2012 17:55:41

For historical reasons (xml.Hash started out as an alias for map[string]string) xml.Hash uses map entries for /next and /last-sibling. It would make the code a bit nicer to use fields instead.

As a first step I would replace

.refs["/last-sibling"]

with

.lastSibling

(and likewise for /next)

Then grep through the source for any remaining "/" (there shouldn't be many). Some tests can be eliminated after this change in iterations of the kind "for ... := range ...refs".

Original issue: http://code.google.com/p/go-susi/issues/detail?id=2

From [email protected] on September 04, 2012 12:46:03

As described in the manual, and do not have the meaning their names suggest. It is possible that GOsa uses and as a range of values to be reported rather than as OFFSET and LIMIT.

Check if GOsa uses anywhere (other than passing 0 and 9999999) and if it uses it according to the actual meaning or the one implied by the names and . If GOsa uses it in the intuitive meaning, change go-susi to implement and as actual range boundaries.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=4

From [email protected] on December 01, 2012 21:11:45

When an siserver passes on a wake request to a peer it uses a trigger_wake rather than job_trigger_action_wake. trigger_wake doesnt create a job or foreign_job_updates.

Implement trigger_wake. It's already documented on the manual.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=33

From [email protected] on October 17, 2012 11:40:22

Right now go-susi transmits its whole jobdb to a peer that sends it new_server. It may be a better idea to only transmit jobs for which the sending server is directly responsible.

Advantages:
The authoritative source for any job is the server that is responsible. The new_server will only get one foreign_job_updates for each job, rather than (possibly conflicting) updates from all servers to which it sends new_server.

After deleting a server's jobdb it will not be regenerated from other servers, which can be really annoying when you try to get rid of erroneous jobs.

Disadvantages:
If not all servers are listed in DNS/address, then a new server will start with an incomplete jobdb.

A server that loses/corrupts its jobdb can not regenerate its own jobs from foreign information.

It becomes easy for jobdbs to get out of sync if a server's jobdb is deleted.

Alternatives:
A middle ground solution between the current behaviour and the one described above would be to filter out from foreign_job_updates only those jobs that are the responsibility of new server. This allows for deleting a server's jobdb to get rid of its jobs but other server's jobs will still get regenerated even if they are not all listed in DNS. The disadvantage of jobdbs getting out of sync remains of course (because it is the flip side of the advantage we're trying to achieve).

Original issue: http://code.google.com/p/go-susi/issues/detail?id=18

From [email protected] on December 21, 2012 15:15:22

Derzeit kann man bei einem periodic job das periodic nicht abschalten
über Verteilungsstatus/Bearbeiten, weil GOsa wenn man die periodic
Checkbox abschaltet, das Element gar nicht aufführt im
Element. Dadurch ändert es sich nicht. Korrekt wäre wenn GOsa
in dem Fall none einfügen würde. Der angehängte
Patch scheint dies zu erreichen.

Attachment: periodic-edit-fix.patch

Original issue: http://code.google.com/p/go-susi/issues/detail?id=36

From [email protected] on September 10, 2012 20:36:11

Currently go-susi accepts commands even if they are unencrypted or encrypted with "dummy-key". This should only work in --test mode. For ordinary operation only encrypted commands should be accepted.
An exception is gosa_ping which is always encrypted with "dummy-key"

Original issue: http://code.google.com/p/go-susi/issues/detail?id=6

From [email protected] on February 04, 2013 18:31:52

Send set_activated_for_installation message in action/activate(). gosa-si does this, too.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=38

From [email protected] on February 18, 2013 18:47:21

Update the manual with most recent reverse engineering info.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=49

From [email protected] on October 17, 2012 20:42:21

gosa-si retries certain jobs (reactivate_job_with_delay()) if a message can not be delivered. Check for each kind of job if that is actually necessary/useful. For jobs that change the faistate in LDAP the client will notice on its own if it has to do something when it becomes active.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=19

From [email protected] on February 11, 2013 14:50:39

Test code from commit 010241e0f138 (double check if another server wants to claim one of our clients)

Original issue: http://code.google.com/p/go-susi/issues/detail?id=41

From [email protected] on September 26, 2012 20:01:54

serverdb.go:addDNSServers() ignores go-susi's own machine if it is listed. The check should be more fine-grained and take the port into account, so that a second server can run on the same machine at a different port without being ignored.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=17

From [email protected] on February 08, 2013 15:05:32

Create a gosa-si-client fix for the behaviour described at the here_i_am message in the operator's manual. When gosa-si-client re-registers due to not being able to decode a message (e.g. a ping encoded with dummy-key or "Müll" as sent by go-susi) it should start again with the server listed in client.conf instead of going to the next server from DNS.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=39

From [email protected] on September 20, 2012 16:46:53

If a job is more than X minutes old (X depending on the kind of job and the state it is in) with no action taken by the responsible server, assume the job has disappeared and remove it from the database.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=12