I have chroot set up for "user" with a work area. I am looking to setup another work area on the same machine, and it is fine if you need to exit user, and login as user2 or something. Is this possible to accomplish and if so, how?
I figured out this answer. All that is needed is to add another entry into /etc/schroot/schroot.conf. Once a linux skeleton is built in there, using debootstrap, then you can chroot into the area without issues!
Related
I am currently working on with a solution that would be able to clone/copy/backup my existing rep:policy. 'Cause when we do some jobs it accidentally removed. I am trying to apply this kind of fix, but am failing to. It says it is an invalid path.
javax.jcr.security.AccessControlException: OakAccessControl0006: Isolated policy node. Parent is not of type [rep:AccessControllable]
final Workspace ws = session.getWorkspace();
ws.copy("/etc/commerce/products/abccompany/TvPackChannelMap/rep:policy","/tmp/nxt/TvPackChannelMap/rep:policy");
Are there other ways that I can be able to take the rep:policy thru code?
You need to make sure that your job does not touch the permissions or the rep:policy, this is the best way forward for you.
The exception could be because of /etc/commerce/products/abccompany/TvPackChannelMap/rep:policy does not exist or the user whose session you are using does not have read access to the node.
Make sure the path is correct, copy paste it to your CRX/DE to make sure it exists.
I have tried to use your code to copy a rep:policy from one node to another, works fine. But I would not* recommend copying permissions that way. The best practice is to use the Access Control Management API for all things permissions.
You can check, install and use the access control tool from netcentric. It offers a jmx interface for exporting AC entries and maybe also some APIs you could use to implement your custom solution.
The Other approach is to retrieve the ACL permissions through the query language.
For example, SELECT * FROM [rep:ACL] or SELECT * FROM [rep:ACE] where [rep:principalName] is not null should give you the results.
For more information, I would recommend you to check the ACS commons ACL Packager Implementation which is available on GitHub.
Reference Link - https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/packaging/impl/ACLPackagerServletImpl.java
I'm new to Perl and to Active Directory.
I need an example code of connecting into
an Active Directory server
(only address, there's no need to login),
and fetch all the details of a user by id.
I've searched the net and found script only
with the use of Net::ldap, but I am forced
to use Win32::Ole. Could someone please help
me to get it right at this way?
The best way is to use Net::Ldap. If you are not able to do so then the second best approach is to use some kind of Windows tool (like ldifde.exe/csvde.exe) and parse its output.
Basic usage: http://ss64.com/nt/csvde.html
More on ldifde: http://blogs.technet.com/b/lifeofapfe/archive/2009/02/19/using-ldifde-to-export-users-from-active-directory.aspx
Regards,
I am working with openstack and I want to pin vcpus to pcpus in guest xml. Now, the pinning operation can be done using
virsh vcpupin guestname vcpu pcpu
But I want to do it using python API. I investigated the openstack code and found out that get_guest_config function in libvirt/driver.py is responsible for generation of guest XML file. Now, I tried to put vcpupin attribute here by guest.vcpupin or guest.cputune_vcpupin but none of them is working. Any idea what am I doing wrong? Or is this functionality not available with openstack?
Okay, I figured it out. You need to define the attributes in the nova.virt.config before using them. After defining the attribute, it's working fine.
In researching this scenario, all I could find was a suggestion that you contact Microstrategy, send them your metadata DB and ask them for the password.
This CAN'T be the only way.
Is there no way to simply reset the password in some fashion? Looking at the DSSMDUSRACCT table in the metadata DB, this appears to hold (at first glance anyway) a hashed/encrypted password, but I don't believe this is correct, as every entry for every account is the same in the PASSWD field.
Can someone suggest an alternative beyond sending a database to Microstrategy?
There isn't any alternative. We ended up in similar scenario and had Microstrategy reset the password. Password is not easily recoverable from Medadata since it is secured.
I'm not sure how many projects you have in your metadata or if you have access to another user that may have all privileges; but another option would be to create a new database, use MSTR configuration wizard to populate metadata tables, then duplicate the project across project sources into the new metadata that was just created. The Administrator user in this new metadata will have a blank password. If this is not an option then I recommend to open a support ticket (as others have suggested).
One of the things which one can try is to see any command manager script or system manager workflow. Every MicroStrategy environment may have atleast one of the above two things running in their environment. If you check the file, you may see the password for the administrator user. But in case if there is none of these being used then contacting MicroStrategy support would be the right thing to do.
Thanks,
Nikhil.
Benedict's right, there's no way they would keep passwords in plaintext in the metadata. You'll have to send it to them in a support ticket. It can take quite a few days, but they get the job done.
as soon as you get it reset use object manager, create a configuration object package for the administrator account and anytime you forget it, just redeploy the package to reset it.
You could try using the MicroStrategy Object Manager to copy the Administrator user from another project source/server to this environment.
This should do the trick if you have at least one other user with the right administrative privileges.
The other day I wanted to login to one of our applications. However, I forgot my username and password. I tried using the forgot password wizard but had no luck.
The steps I am about to walkthrough will work with most web applications with average logon security measures. It may not work with MicroStrategy, but should work if the input password is not externally verified.
So this is how I got access:
First I logged into my database manager -If you don't have access to
this... run a scan for 'password' on your server root. For Linux I
write sudo grep 'password' -roni or try: db_pass, dbpass,
database_password, etc as other search terms... The -roni will apply various filtering and
options to the search... aka line number, file name and etc. After
getting some results... find a likely file and open it to see if you
have your database details in there.
Login to your database manager. Find the table associated with your account. (This will usually have the name X_users If the password isn't hashed, just take it and login with it... if it is hashed... copy the hashed value to your clipboard.
Change the directory to your chosen applications root.
Run the scan with the search term 'password' or 'md5(' ...this will hopefully bring up a login controller file.
Edit the line within the function that takes your login input. Change the value 'md5($#####)' with '$#####', (aka removing the md5hashing of your input).
Reload the login page. Now, enter your username and hashed password copied from the database and login.
If done correctly you should now be logged into your web app.
Change the password of the account. Now go back to the login controller file and undo the chnages.
This might not be applicable with your app in question, but it's worth a shot! ....and if it isn't appropriate for your scenario... it could still be very helpful for someone else with a similar problem and different application. I just thought there's a small chance it may help someone who's locked out of one of their web applications. Rather than having to reinstall and lose data.
I'd be happy for you to improve on this or give some feedback.
I'm very new to Perl, and I have absolutely no idea how to approach this. We have an old Perl application which previously used Apache auth; we'd like to replace this with a cookie based form-style authentication. I understand that this is very case-specific, and there is no one answer as such, but some general tips would be much appreciated.
Will I need to edit all .pl files in the website? Or is there a "golden hammer" solution I can use? Is there something on CPAN I can use? We're using Perl v5.8.8 if it matters, and we're using Apache 2 shared hosting. I am happy to provide additional information as is necessary.
For the authentication to be recognized/required, it will need to be checked by the .pl file that initially receives the user's request. So the answer to whether all .pl files will need to be changed depends on how your application is structured:
If the user goes to http://myserver.com/one.pl to do the first thing and http://myserver.com/two.pl to do the second thing, then, yes, you'll need to change them all because they're all receiving requests individually.
If the user goes to http://myserver.com/dispatch.pl?mode=one for the first thing and http://myserver.com/dispatch.pl?mode=two for the second thing and dispatch.pl calls either one.pl or two.pl behind the scenes based on the mode parameter, then you only need to change dispatch.pl, since it's the only one directly receiving requests from the user.
Edited to add: If you're dealing with the first model, then I'd strongly recommend setting up an external module (.pm file) with the cookie-handling code and calling that from each of your individual .pl files instead of duplicating that code all over the place. Ideally, this would let you get by with only a few lines of added code in each .pl:
use MyCookieHandlingModule qw(verify_cookie redirect_to_login);
my $q = CGI->new; # ...unless you're already using CGI in object-oriented mode
redirect_to_login unless verify_cookie($q);
You could do it at a level outside the Perl program.
Thanks for your answers guys, but I eventually decided on CGI::Session::Auth::DBI which works well on shared hosting.