I need to use Trac for project management, but I am having problems with authentication. I don't have Apache, I'm using nginx and the tracd server.
To create the user, I used the command:
htpasswd -c /home/ubuntu/trac/projeto/.htpasswd usuario
To upload the service I'm using the following command:
/home/ubuntu/trac/virtualvenv/bin/tracd -p 3050 --basic-auth="/home/ubuntu/trac/projeto,/home/ubuntu/trac/projeto/.htpasswd," /home/ubuntu/trac/projeto
When I call the project in the browser, the login window is presented to me, which always fails, even informing the user and the correct password.
what am I doing wrong?
Try: --basic-auth="projeto,/home/ubuntu/trac/projeto/.htpasswd,trac". See TracStandalone for details.
Related
Hello
i am working on the IBM webseal authentication. i want to implement the webseal authentication into my application.
while configuring the runtime component i am getting the following error.
Unable to verify the management domain location DN in the
LDAP server: (secAuthority=Default).
If the location does not exist on the server, create it,
otherwise specify a different location that does exist.
Error: DPWAP0003I An error occurred while executing the command: /opt/PolicyDirector/sbin/PDMgr_config -s TRUE -y no -v TRUE -d CN=jony mittal,OU=dev,DC=dgad,DC=com -w XXXX -L 389 -C fips -D Default -m XXXX -l 1460 (0x1)
anyone please help me to resolve this issue.
thanks
When you are configuring ISAM/ISVA PD runtime, PDMgr_config will deploy its registry into your LDAP directory server. This requires modifying the schema of the LDAP server. To do this, it requires administrator rights on the directory. Commonly this will be an account such as cn=root, cn=admin, cn=DM, etc. depending on your directory server.
I believe what may work better for you, if you are configuring ISAM from scratch, is likely deploy using the internal/embedded LDAP. When configuring the runtime choose the local LDAP server option. You can set the credentials on the local/embedded LDAP server on the tab where you configure the runtime. Just set a password on it, then feed that password into the runtime configuration.
Then, if you are needing to tie into another directory, which I expect is the case since you are trying to do this now, then use basic user mode with a "federated registry" so you don't have to deploy the ISAM "registry" and hence do not have to modify the existing directory. This way you can authenticate and authorize users off an existing directory without having to modify that directory specifically to support ISAM.
Additional information here:
Embedded (local) LDAP server instructions
Configuring PD runtime
Basic user mode instructions
Setup federated repository
I tried using the ejabberd register
command but it tells me command not found
I updated to 20.04 and now i cant login anymore
Maybe the script is called ejabberdctl:
$ ejabberdctl register someusername yourserver somepassword
Other idea: if you have mod_register enabled and it allows registration, you can register an account using a Jabber client.
I created an application on existent OpenShift project by pulling a docker image from remote repo.
The pod is created but fails with STATUS "Crash Loop Back-off".
Invesitgating the reason using
oc log <pod id> -p
it appears a list of unsuccessfull "chown: changing ownership of '...': Operation not permitted
I found this is due to non predictable user id running the container.
According to
https://docs.openshift.com/container-platform/3.6/admin_guide/manage_scc.html and various post here and there,
it seems the solution is to relax security policy:
oc login -u system:admin https://<remote openshift endpoint>
oadm policy add-scc-to-group anyuid system:authenticated
If this is the solution, I don't know, because I cannot get out of 1st problem:
oc login -u system:admin
asks for login/pwd and after print an error
error: username system:admin is invalid for basic auth
I guess there is the need of a certificate, a token, something secure, but I cannot understand how to generate it from Openshift, or
if there was a key pair to generate locally (of which kind) and how to bind the key to the user. Furthermore, checking in the web console
I cannot see that kind of user (system:admin).
Am I missing something?
Thanks a lot,
Lorenzo
I am on a Solaris 10 machine with opendj 2.4.5 installed. I am attempting to set a user's password with the ldappasswordmodify command. In my application I want to be able to set their password without requiring the previous password. I still need the password to obey the history and validation requirements though. I have this working on a similar machine that I set up a while ago and am not sure how I did it.
This is how I am calling the command:
ldappasswordmodify -D cn=mgr -w mgrpw -a uid=user,ou=people,o=systems,dc=program -n newpassword
No matter what password I give it the command works and sets the password.
If I use the command and supply the old password like this:
ldappasswordmodify -D cn=mgr -w mgrpw -a uid=user,ou=people,o=systems,dc=program -c oldpassword -n newpassword
The history and validation requirements are enforced properly.
Does anyone have any idea how to do this or perhaps what to check on the working system to see how I did it before? I'm at a complete loss.
Don't use the manager account. Don't use it for anything actually. Use a user account. The manager account is for slapd itself. It bypasses a lot of security and overlays.
I think this was an issue in OpenDJ 2.4 and it has been resolved in later versions.
You might want to try with OpenDJ 3.0 which is the later release available.
I am starting with meteor [version 0.3.8 (7510b8430e) on OSX] and cloned one of the examples. I peppered my server side with a couple of console.log() statements and am trying to look at the output. According to the manual it is
meteor logs <site>
but that command asks for a authentication? What am I missing?
Did you at some point run
meteor deploy yoursite --password
or
meteor deploy yoursite -P
? If so, it's the password that you set at that time. If you're sure you didn't, maybe somebody else beat you to it (since anyone can set the password on a deployed app with no password)?