I've been using duplicity for several months to back up my mac. I recently needed to do a restore, but it looks like at some point I switched keys. Because if I use Key A, it starts to open a few volumes then complains that a volume was signed with Key B, but if I switch to Key B, it complains that the first volume was signed with Key A. The manpage indicates multiple sign keys are not allowed. Did I wreck my backup? Both GPG keys are on my keyring, just some volumes were backed up with one, some with the other. Advice?
Thanks,
PeterT
In my conf file, setting GPG_KEY='KEYA,KEYB' and GPG_KEY_SIGN='disabled' solved the problem. I have no idea why duply started using two different GPG keys from my ring (probably because I was still learning), but I am now deleting my entire backup and starting again (and removing all duply GPG keys and making a new one).
Related
I've deleted all my nodes and relationships (Delete all nodes and relationships in neo4j 1.8), but I see that in Neo4j Browser the "property keys" that existed before the deletion remain.
See the picture below:
How can I make all the "Property Keys" go away too, so I can end up with a fresh new database? I understand this orphan property keys do not pose a problem themselves, but they clutter the browser experience and will start confusing with newer properties.
Thanks!
You should be able to clear everything out by:
stopping your Neo4j database
deleting everything matching data/graph.db/* (look inside the graph.db folder)
starting up again.
What version of Neo4j are you using? Prior to to version 2.3 there is a file named keystore in the data/ directory that was used to populate this in the browser. Deleting this file will clear out the Labels, Relationship Types, and Property Keys listed in the browser.
Looks like this has changed now with Neo4j 2.3 so if you are using the latest version I don't think you'll have this file.
In the manual you can see that there is currently no way to disentangle which property keys are currently used without traversing the graph.
http://neo4j.com/docs/stable/rest-api-property-values.html#_property_keys
Which is a bummer because I'd like to do the same thing. TBC.
I have Neo4j Community Edition 3.2. To get rid of the property keys (and get rid of the entire DB), I completely uninstalled Neo4j, deleted the Neo4j folder in C:\Program Files and then reinstalled the package again so that I had a fresh DB to work with. Not ideal to delete everything but it worked for me.
I got rid of the properties by open a new DB.|(I didn't want to delete my old folder )
Create a new folder beside the default folder
stop the server
choose the new folder and start again a new DB with new PW
Actually, there is not a way to just delete the unused properties. You need to recreate the graph or use a tool to copy neo4j stores called "store-utils".
I had to change my Apple ID, but I have numerous important records in the production environment in a container of my old Apple ID.
Can I export them while maintaining the dependencies and record authors?
Short answer: No
But you could manually copy over records from one container to the other (or first create an export and then create an import). But then It will look like new data in the new container an it will also have new metadata. So the creator will be the account used to migrated the data. And you would need an app (OS X or iOS) that can connect to the production public container.
just tried to create a snapshot of one of my projects. It didn't work, and Xcode did throw the following error at me: "Unable to create a snapshot. fatal: You don't exist. Go away!"
Source control commit doesn't work either. Ok, obviously there's something wrong with my local repository. I don't have the slightest idea, what that could possibly be, though. I have not committed in quite a while, but except some updates to Xcode itself, nothing major happened to the project folder, as far as I can remember.
So, what can I do about it? Is it possible to deactivate source control for that project and then start over again with source control with the projects current status? I don't need the previous versions anymore, so that doesn't need to be taken care of.
Thank you!
Looking into the git source code, this error message is generated only if
pw = getpwuid(getuid());
fails.
It indicates that the system wasn't able to find an entry for your user account in /etc/passwd or equivalent.
This can happen if your account is removed (via deluser, userdel, or something else) while you're logged in, or if you don't have read permissions on /etc/passwd (the latter should never happen).
Try the following commands at a terminal prompt:
whoami
id
ls -l /etc/passwd
grep "^${USER}:" /etc/passwd
According to the git documentation, this is the meaning of your particular error:
You don't exist. Go away!
The passwd(5) gecos field couldn't be read
This typically means the system doesn't know who you are (you'll see this sort of error on a Linux system if you delete someone's user account while they're still logged in). Is everything else working? That is, can you log out and log back in without a problem? Do other terminal commands operate correctly? What about the id command?
Can you interact with your repository on the command line? What happens if you cd into the directory and try something like git status?
WendiKidd's solution of just starting from scratch is probably the simplest thing to do, assuming it works, but you'll lose any change history already associated with your project.
I had this issue with git and running
dscacheutil -flushcache
in the terminal fixed it.
I would suggest creating a new project entirely, copying your code etc. files out of the old project, and simply migrating over into a new one (which you could then recommit to another source control directory). That seems like the easiest solution; this is a very odd error, and I've come across things in the past that are either unfixable or would take more effort to fix than taking 10-15 minutes to just set up a new project.
So that's what I'd recommend--hopefully that will fix your problem, and whatever xcode is mad at is in some hidden file or the .xcodeproj itself, and not in the files you'd need to migrate over.
Symfony worked great for us when we were a small team of trusted developers. Now however, we are getting more people to help out, which leads to a problem with managing production passwords checked into source control.
I have production passwords for our DB, API keys, etc. stored in the Symfony config files which I do not want all developers to have access to. How can I hide these passwords from unauthorized developers and yet still grant them access to the source code?
If you're already using a version control: your first stop should be removing all passwords from the history in your versioning system. Good luck ;-)
Next: isolate the files which have passwords in them. (Probably config/databases.yml and apps/<yourapp>/app.yml.).
Copy/rename this files to *.yml.dist (for example: config/databases.yml.dist). Clean up all production passwords from these files, and leave only
the bare minimum to keep it going.
Make sure the original files don't appear in your VCS ever again. (svn ignore, or the likes).
Now when you set up a new environment, you can just copy the *.dist files to their 'real' names.
(What I did for my project is move all API keys to a single apikeys.yml in the config directory. That way all the properties in the app.yml keep being versioned, and my api keys don't appear in the VCS.
Hope you get the answer for your question. Recently I have implement these kind of works in my project.I think to store these kind of confidential data database is the safe options and get this data using filter is the best option no need to store your data in app.yml.
I've got some large problems with my ruby on rails deployment on EY. Support has said I need to SSH in to clear the errors... but I get the following:
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
80:4c:5f:dd:98:bb:cb:01:6c:a9:11:41:29:56:66:86.
Please contact your system administrator.
Add correct host key in /Users/jameshughes/.ssh/known_hosts to get rid of this message.
Offending key in /Users/jameshughes/.ssh/known_hosts:1
RSA host key for ec2-184-73-167-153.compute-1.amazonaws.com has changed and you have requested strict checking.
Host key verification failed.
[Process completed]
How do I add the correct key to the Known_hosts file?
Open up known_hosts in your favorite text editor, find the entry for "ec2-184-73-167-153.compute-1.amazonaws.com" and delete the entire line. The next time you ssh in, it will add the correct key to the known_hosts file.
Note that this error is for security purposes, so I'm assuming that you know that there is not a "man-in-the-middle" attack going on and that the server key has actually changed. If it has not, there might be something else going on.
To fix your "Permission denied (public key)" problem, you'll need to add your public key to engineyard via the Tools menu, then apply your changes to your environment (by clicking apply).
Hope that helps.
Update
Please see #womble's comment below and my reply. As #womble notes, if you use StrictHostKeyChecking no you will be open to man in the middle attacks. I've talked with EngineYard about this (last time I checked, StrictHostKeyChecking no was what they were recommending in their help documentation). I believe using StrictHostKeyChecking=ask is a better alternative. Does anyone else know if there is a better solution than using StrictHostKeyChecking=ask?
I ran into the same issue and this seemed to work for me. You just need to add "StrictHostKeyChecking no" to after "'~/.ssh/config'':"
Engine yard has a pretty good article on it. The Man in the middle issue is near the bottom.
http://docs.engineyard.com/ssh-keys-and-configuration.html
Now when I SSH I still get the warning, but am able to access the server. I started getting the warning after I stopped and restarted my instance.