You will not loose your logbook data if you have access rights to the file system where the "elogd" program writes it's data.

The easiest way is to edit there password file directly and then restart "elogd".

But even if you do not dare to edit the files directly, you still can solve the issue from the web interface:

• Create a new account, e.g. user "admin2"
• While logged in as "admin", make this user an administrator: go to "Change config file", add "Admin user = admin, admin2"
• Now log off and then login as "admin2"
• Check that you can do administration, then remove user "admin"
• Create a new user "admin" with proper "Full name" and "Email"
• Now log off and then login as "admin"
• Check that you can do administration, then remove user "admin2"

That should work. Good luck!

If you start over, you can just copy the xxyyzza.log files into the new logbook directory and it should be fine. You can also change the config file in your current logbook without starting over. 

Best is if you edit elgod.cfg or the user configuration from inside the web browser (Click on 'config' on the elog page), then you don't have to restart elogd. If you do have to restart it, go to My Computer/Manage/Services, select elogd, then stop and start the service.

- Stefan

 Fantastic! That worked great. Thanks so much for the help guys!!

Terry

You can allow guests to create entries, but only registered users (Admins) to delete (or edit) entries:

See https://midas.psi.ch/elog/config.html#general for details.

> I noticed that when I put in a password such as <test1> a person can login 
> with the password <test2> or any other number at the end.  Is the 
> encryption not able to tell the difference between numbers?  The encrypted 
> passwords even look the same in the password file.  Is this a bug?

This is really strange. Encryption only works on ASCII characters and does 
not distinguish between letters and digits. When I try to reporoduce that, 
the system distinguishes well between "test1" and "test2". The first gives 
encrypted "dGVzdDE=" and the second gives "dGVzdDI=", note the different "E" 
and "I". So I have no clue right now what is wrong in your installation. If 
running under Linux, you can compile elogd after adding "-DHAVE_CRYPT" and "-
lcrypt" to the Makefile to use the standard Linux crypt() function, but I 
would rather like to understand what is wrong in your case.

- Stefan

> > I noticed that when I put in a password such as <test1> a person can 
login 
> > with the password <test2> or any other number at the end.  Is the 
> > encryption not able to tell the difference between numbers?  The 
encrypted 
> > passwords even look the same in the password file.  Is this a bug?
> 
> This is really strange. Encryption only works on ASCII characters and does 
> not distinguish between letters and digits. When I try to reporoduce that, 
> the system distinguishes well between "test1" and "test2". The first gives 
> encrypted "dGVzdDE=" and the second gives "dGVzdDI=", note the 
different "E" 
> and "I". So I have no clue right now what is wrong in your installation. If 
> running under Linux, you can compile elogd after adding "-DHAVE_CRYPT" 
and "-
> lcrypt" to the Makefile to use the standard Linux crypt() function, but I 
> would rather like to understand what is wrong in your case.
> 
> - Stefan

Ok, try it with the passwords <hello1> and <hello2>.  Then when you go to log 
in, put in the password of <hello> with any single number after it and let me 
know if the problem shows up for you because that is the password I was 
using.  When I look at it encrypted in the passwd file they look the same.  I 
also installed the latest version today which is newer than the one I was 
using before and it still does it.  I appreciate your time.

Byron

> Ok, try it with the passwords <hello1> and <hello2>.  Then when you go to 
log 
> in, put in the password of <hello> with any single number after it and let 
me 
> know if the problem shows up for you because that is the password I was 
> using.  When I look at it encrypted in the passwd file they look the 
same.  I 
> also installed the latest version today which is newer than the one I was 
> using before and it still does it.  I appreciate your time.

Ok, I finally found the problem: Whenever a password has a length which can 
be divided by three (like 6 or 9), the last two characters are completely 
ignored. This problem will be fixed in version 2.3.5. Is has to be noted 
that all existing passwords with the mentioned length have to be re-entered 
after the upgrade from 2.3.4 to 2.3.5. Since one cannot log in with the old 
password on those cases, a "Forgot password?" links has been added to the 
login screen, which can be used to create a new password and send it to the 
registered email address.