Re: Synchronising between physically separate networks, posted by Stefan Ritt on Thu Jul 10 12:46:52 2008
|
| Dougie Mooney wrote: |
|
Hi there. Just started recently set up the application and think its very usable and easily configured - great stuff 
I'm looking to roll it out to the masses but have a slight logistical problem in that we work on 2 separate networks - NET1 with connection to the internet, and NET2 physically isolated from NET1 and the internet.
It would be desirable to allow users to add/update/delete logs from both NET1 and NET2 with periodic synchronisation.
I believe the mirroring facility is what should be used, and think the following setup and synchronisation steps may be workable:
Setup:
- elog installed on node of NET1
- elog installed on 2 nodes of NET2
- elog server running on NET1 and node1 of NET2 both using a common elogd.cfg
Performing Synchronisation:
- Stop the server on NET1
- copy logbook directories from NET1 to node2 of NET2
- start server on node2 of NET2 using the -M option
- once above complete, copy logbook directories from node 2 NET2 to NET1
- Start the server on NET1
Am I on the right track?
Would very much appreciate comments and and advice on the above.
|
A couple of comments:
- In principle you could use one elogd.cfg for two running daemons, but only if they do not modify the file. If you use "extensible attributes" for example, you would have write access. If this happens from both servers at the same time, the config file can get corrupt. This is even more true with a password file, which gets written every time a users accesses a page. If you only run one server at a time, then they can share the config file of course.
- The synchronization works bi-directional between two elog daemons. Requirement is that they have access to each other. The synchronization master acts like a "browser" to the slave to send/retrieve entries. So if you can affort punching a hole into your firewall between NET1 and NET2, you could synchronize two servers directly and don't have to bother with three servers. If you have however really physically separated nets, such that you need a memory stick to transport data from one net to the other, then indeed you need the above described scenario. I never tried it in this way, but in principle it should work.
|
Re: Problems with elog client, posted by Yoshio Imai on Thu Apr 10 15:56:12 2008
|
| Stefan Ritt wrote: | | As I wrote in my previous message, the "SSL part has not been tested" (=means: does not work). |
Sorry for the misunderstanding. I was probably confused because the creation of new entries already worked, even with SSL.
Now, the editing also works.
Thank you very much!
Yoshio |
|
Re: Problems with elog client, posted by Yoshio Imai on Thu Apr 10 14:21:13 2008
|
I have tried the new revision, recompiling both client and server.
Unfortunately, the overall situation has not changed. We can still create new entries using the elog client, but editing an existing entry still does not work. However, thanks to your patch, the -v option now works again for the client side:
> elog -s -h <elog server> -p 443 -l current -u <user> <password> -a <Attributes> "TEST ENTRY"
Message successfully transmitted, ID=1
> elog -s -h <elog server> -p 443 -l current -u <user> <password> -e 1 "EDIT THIS ENTRY" -v
Successfully connected to host <elog server>, port 443
Request sent to host:
GET /current/1?cmd=download HTTP/1.0
User-Agent: ELOG
Cookie: unm=<user>;upwd=<password>;
Response received:
ET
Error transmitting message
Again, there is no output on the server side even when running with -v in console mode. There is the expected output when an entry is successfully created using the elog client. One aspect about this output is strange, though: the "Return" statement==== Return ================================
HTTP/1.1 302 Found contains the wrong "Location" header. It is notLocation: https://elog-server.domainname/logbook/ID but ratherLocation: https://client-host.domainname/logbook/ID where "client-host" is the hostname of the computer where the elog client was called. But, since the logbook entry is correctly created, this is perhaps not a problem at all.
Another thing: I have noticed that when using conditional preset texts, the "Preset Text =" statements have to be declared for each logbook of a logbook group; it is not sufficient to only declare it in the "[global]" section of the logbook group. This means that we only need to declare the conditions once, e.g.
Options Category = .... , Shift {1} , ....
{1} Options Subject = Shift start {a}, Shift end {b}, ....
but the preset text declarations{1&a} Preset text = shift_checklist.txt
{1&b} Preset text = shift_summary.txthave to be declared in every individual logbook section for the logbooks of this group. Is this expected behaviour, or a bug?
Cheers
Yoshio |
|
Re: Problems with elog client, posted by Stefan Ritt on Thu Apr 10 15:39:26 2008
|
| Yoshio Imai wrote: | > elog -s -h elog -p 443 -l current -u <user> <password> -e 1 "EDIT THIS ENTRY" -v
Successfully connected to host elog, port 443
|
As I wrote in my previous message, the "SSL part has not been tested" (=means: does not work). I just fixed this today, so try revision 2100. |
|
Re: Problems with elog client, posted by Stefan Ritt on Tue Apr 15 20:34:49 2008
|
| Yoshio Imai wrote: | Another thing: I have noticed that when using conditional preset texts, the "Preset Text =" statements have to be declared for each logbook of a logbook group; it is not sufficient to only declare it in the "[global]" section of the logbook group. This means that we only need to declare the conditions once, e.g.
Options Category = .... , Shift {1} , ....
{1} Options Subject = Shift start {a}, Shift end {b}, ....
but the preset text declarations{1&a} Preset text = shift_checklist.txt
{1&b} Preset text = shift_summary.txthave to be declared in every individual logbook section for the logbooks of this group. Is this expected behaviour, or a bug?
|
I cannot reproduce your problem. I just tried following file:
[global]
port = 8000
password file = passwd
Options Category = Other , Shift {1} , Routine
Attributes = Author, Category, Subject
{1} Options Subject = Shift start {a}, Shift end {b}
{1&a} Preset text = shift_checklist.txt
{1&b} Preset text = shift_summary.txt
[demo1]
Comment = General linux tips & tricks
[demo2]
Comment = General linux tips & tricks
and it worked as expected. Can you try it? If it works for you as well, then try to morph this file towards your config file, and figure out when the unexpected behavior starts. |
|
Re: Problems with elog client, posted by Yoshio Imai on Thu Apr 17 19:11:36 2008
|
I have tried your sample config file, and this one also works for me.
The problem arises when using top groups. I have produced a minimal config file including a top group, of the form
[global]
logbook tabs = 1
SSL = 1
Theme = default
Top group testgroup = demo1, demo2
Show top groups = 1
[global testgroup]
Attributes = Author, Subject, Type
Options Subject = ThisOne{1}, Shift info {2}, ThatOne{3}
{1} Options Type = OneType1, OneType2, OneType3
{2} Options Type = Shift start {a}, Shift end {b}, Info
{3} Options Type = TwoType1, TwoType2, TwoType3
Required Attributes = Author, Subject, Type
{2&a} Preset Text = shift_checklist.txt
{2&b} Preset Text = shift_summary.txt
[demo1]
Comment = DemoLog 1
[demo2]
Comment = DemoLog 2
Although the conditional attributes work for the logbooks demo1 and demo2, the preset text does not work. It works when the Preset Text= statement is (also) places in the individual logbook sections. Can you check if it behaves the same on your side?
Yoshio |
|
Re: Problems with elog client, posted by Stefan Ritt on Thu Apr 17 21:23:06 2008
|
| Yoshio Imai wrote: | | The problem arises when using top groups. |
Uff, that was a tough one. Thanks to your detailed analysis I could reproduce the problem. It indeed only happens with conditional 'preset text' under a top group (which is so exotic I have never tried it before). I fixed that in SVN revision 2103, please download and test it. |
Re: Help me please I can't uplode Attach file, posted by Mark Soohoo on Sun May 18 06:20:00 2008 
|
| Stefan Ritt wrote: |
|
| Samrit wrote: |
|
Dear All
I can't uplode Attach file. It have Error
| Error: Filename "D:\aaa.doc" contains invalid character |
| Please use your browser's back button to go back |
Thank you very much
Joe..
|
The problematic part is the "\" in the filename, which is not correctly recognized as a directory. I will fix this in the next release. For now, just click on the Browse button, navigate to d:\, and then select there the file aaa.doc.
|
Hi, I'm having the same problem, too, when attempting to upload an attachment. I'm using version 2.7.3-2095.
I wasn't able to attach an image by clicking on the Browse button, clicking on the desired file, hitting the Open button, and then hitting the Upload button. I just noticed that I could upload my error screen to this forum:
Thanks for any help you can provide.
Mark
|
|