I have a Pro JFrog Cloud account and I can't empty my Trash Can. (It contains 1.32GB data.) I tried to follow this article, but I can't find the
"Trash Can settings" above Look & Feel Settings. Is it removed from the UI?
I also can't find Usage statistics on my Admin page although I am admin. I don't know if this is relevant.
As you are a cloud customer, I assume you are version 7.x, while the document you shared is of Artifactory 6.x, and hence looks different than your instance.
The same should be found under Administrtaion->(Services)Artifactory->General->Settings, and then scroll to the bottom. There, you will be able to enable/disable trash can, set its retention period, and empty the trash can.
Additionally, you should be able to right click on the Trash Can in Application->Artifacts and "Empty Trash Can".
Note that you may also use the "Empty Trash Can" command using REST API, which is:
curl -XPOST -u user:password https://SERVER-NAME>.jfrog.io/artifactory/api/trash/empty
Related
Firebase hosting allows us to create multiple sites under a single hosting account, which is awesome. After extensive work, I am satisfied with my 2nd site that I created under my project, and no longer need the default site (circle in red).
Sense the default site can't be deleted by default in the browser, is there a way To either delete it, redirect it to another site in the same project, or disable it so that its not publicly visible on the web, all from the CLI command line?
I have red the guides, and I have tried...
adding targets to my configuration file
running the following command line: firebase hosting:delete <default site>
but no luck.
What have people done in this situation?
Firstly you will have to disable the the site then only you will see the delete action.
You could run firebase hosting: disable through the firebase-tools CLI first. Then you will see a delete action under "three vertical dots".
I would like to set up our long running nexus (currently updated to 2.10) for project specific permissions, so that users are limited to access only a part of the repository.
I found this article and this one which exactly match what I am looking for.
So I set up our config like this.
The regexp for us is: ./de/mycompany/myproject./.*
But there is still one error:
I can log in with restricted view and in the search I just see the filtered artifacts. Which is great. But the bottom part of the UI where the repository tree is shown, is empty. Instead I get a 403 error. Looking in the system feed for authentication I find:
Unable to authorize user [myuser] for read(HTTP method "GET") to /nexus/service/local/repositories/releases/index_content/ from IP Address 192.168.0.41, user agent:"n/a"
"releases" is the name of our repo, for a part of which the user is permitted. So what to do to get access to this strange index_content? Do I need another privilege or role? Or another regexp? Using ./index_content/. does not work.
Well, as nobody knew a solution a did a lot of try an error at the weekend. Finally I ended with added a second regex just with a slash ("/"). Now it works as expected and documented in the referred articles.
Right, you need to add permissions for the directories along the path for "browse storage" to work.
See here for more information: https://support.sonatype.com/entries/21592111
I'm using Products.Reflecto in Plone 4 to mirror file system content and provide fine-grained security on that content (i.e. give specific groups access to selected folders)
I know Reflecto objects are not real Plone content, however there is a sharing tab on all the files inside the Reflecto object. It works as expected, until you reindex the reflector at which point the settings are only applied to the reflector object.
E.g.:
Mkdir (on the file system) -p test/foo/bar/baz
Create a reflector object mirroring a "test" directory on the file system.
Share "view" permission on baz with any user or group
Verify that sharing works as expected
Reindex "test"
Notice that the user or group now has "view" permission on "foo"
Curiously, as soon as you configure sharing on a child object the reflector object has the same settings, but they seem to be ignored. Also curious, if you configure a "live" reflector sharing does not work at all. Is this a bug or a feature? Is it reasonable to try to support this use case? I.e. reindex the reflector and maintain sharing settings?
I don't think this was ever meant to work; I don't recall covering the use case when developing Reflecto in any case.
I haven't touched the product in years though, and I didn't do any more than glance at the code base to remind myself.
What I suspect in your test case is that the sharing information is set (via acquisition) on the reflector object, but the directory proxy for baz is being reindexed. If you were to reindex the reflector the sharing settings would no longer be ignored.
If so, then the presence of the sharing tab on the directory proxies is the real bug here.
I ran into some trouble modifying my product and reinstalling it, so I tried installing the version I know works on my live site.
Still no love, just an error message I can't decipher which seems to contain spam! Any suggestions as to how I can diagnose this or where to seek help?
This pastie has the error, truncated due to size:
http://www.pastie.org/2715995
Come to think of it I did see an unidentified user listed at one stage...
Thanks!
Most likely, your site has been compromised by an automated script exploiting CVE-2011-2528. The script adds accounts, changes passwords of existing accounts, and customizes your main_template macro.
In order to clean this up, you need to:
Install the Plone Hotfix.
Reset your session secrets to prevent reuse of old session cookies the attacker may still have.
Audit the accounts present, removing any you do not know, especially if they Administrator access.
Clean up your main_template macro. If you never customized it through the web, simply delete it from your portal_sites/custom folder (go to the ZMI, select portal_sites, select custom, and delete), otherwise edit it and remove the hidden links at the bottom.
So I'm pretty sure my site's been infected with some kind of trojan or virus that attached itself to the scripting within the site. Every time I try and update my Drupal-based site, I get a white screen with this stupid "i'mhere" message. Upon reload, the changes will take affect but I don't know what this is doing once changes are saved. This only pops up while adminstering the site, I.E. posting new content, activating/deactivating modules etc.
Problem is, I haven't the faintest idea how or where to go to remove this. The source code doesn't make reference to any malicious code. It isn't the iFrame link kind of trojan that I've seen brought up through trying to find an answer to this problem.
Things I've tried:
-Scanned computer multiple times for virus (supposedly these things attack insecure FTP data & hijack your client to upload malicious code)
-Changed FTP credentials
-Changed admin user passwords to the backend of the site (Drupal login)
-Updated Drupal
Nothing's worked so far and I'm at my wit's end trying to figure this out. Any tips in the right direction would be greatly appreciated.
Assuming the problem is really Drupal, first check to see if there's some code in a module somewhere firing during a form submit. If you have shell access and it's a Unix/Linux/etc.-based server, navigate to the Drupal directory and run:
grep -r "i\'mhere" *
This will tell you if it exists in code and what file contains it. If it's a module (likely), disable it and either see if there's an update or modify it yourself.
If it's not in code, check your database. Create a dump of your database, and run:
cat databasedump.sql | grep "i\'mhere"
Where databasedump.sql is the name of the database dump you just created. This should at least give you a general idea of what table the data exists in. Then, you can decide how you want to proceed: restore from a previous backup, delete the offending data, etc.
If it's not in either, it might be local. Check with others to see if it's occurring for them.
If it's not local, you've got something really nasty and hopefully someone else has some other ideas on what you can check. :)
Here are a list of potentially useful tools which can help you alleviate, reduce or prevent a virus infection:
bdcored chkrootkit clamd drwebd ipfw iptables kav lidsadm
logcheck logwatch ninja nod32 ossec portsentry rkhunter
sav sawmill shieldcc snort sxid sysmask tcplodg tripwire
uvscan wormscan zmbscap
It is coming straight out of an infamous backdoor malicious software, described on this stackoverflow article.
You may want to manually search for other instances of the virus by running this simple command:
[~] grep -r "base64_decode" .
as suggested in this RAT infection article on thegothicparty.com:
http://thegothicparty.com/dev/article/server-side-virus-rat/