I've just changed our authentication methods for connecting via SSH as we're moving into production for our app, we're also in the middle of migrating to EC2#AWS.
Its been a few days now and I've started to notice a few little changes whcih seem small but none the less, causing me to make mistakes as we run through command lines.
We disabled root logins to start with and now working on a range of users, all with different keys etc.
We no longer get our login 'introduction' when we login. We had some pretty useful information on there which we enjoyed reviewing - Where is that stored and how do we get it back or rebuild it?
We cant 'tab' to autocomplete the filenames anymore. This probably saves us tens of hours a week in typing so would be nice to get this back.
Im sure theres a configuration file somewhere but the files I've reviewed give little to no clue on either of these issues.
Related
This is less a question and more of an answer to this issue that caused me several hours of aggravation. I did find the solution online but not in a direct or easy place.
It turns out that the problem actually had nothing to do with whether I was using test or live keys on my site.
I had deployed my code to heroku, updated my env to match the live keys and received the error listed in the title of this thread.
The solution is actually pretty simple and the problem actually exists in stripe not my code.
I had defined Subscription Plans in test, I then had to create new plans for the live version (no import ability, but that is a frustration for another day).
The problem is that you actually have to go back into your test plans, temporarily rename them, and then rename them back.
So if I have Plan-A in test and I create Plan-A in live, I then need to rename Plan-A in test to something else like Plan-A1. Then I can rename it back to Plan-A and Stripe then works properly.
Anyway, I hope this solves the issues for others because it is really annoying to try to figure out what is wrong and blaming your code is not always the case.
While trying to get GitLab Kanban Board to run nicely with my GitLab server I somehow managed to get myself locked out of the latter. Whenever I open the GitLab-URL now there's the message "No authentication methods configured" and no option for logging in.
Unfortunately, I don't even remember the exact settings that I was messing around with at that time, because it was a while ago and it's only now that I found the time for dealing with this problem again. IIRC one of the last things I did was to try and get OAuth working. (And I think that I was changing some settings in the web interface last, not in the settings files.)
Unable to find a solution online, one of the things I tried was to do a backup and then restore that on a different server. But the result is that I then get the same message on the new server also.
Does anyone have any idea on how to recover from this situation? Is there any way for example to enable "normal" login again by changing settings in the database?
If it's not (easily) possible to recover the whole GitLab installation, is there some way to somehow at least extract the bug report data from it? That's the data that I would be most unhappy to loose...
I'd really appreciate any help, because I'm completely at a loss right now!
You can use the Rails console to reenable your sign-in.
sudo gitlab-rails console
s = ApplicationSetting.find_by(signin_enabled: false)
s.signin_enabled = true
s.save
This will modify the rails settings directly.
As of version 10.5.X, use this instead (different ApplicationSetting key)
sudo gitlab-rails console
s = ApplicationSetting.find_by(password_authentication_enabled_for_web: false)
s.password_authentication_enabled_for_web = true
s.save
I'm making an app in the Cloud9 IDE using Node.js with the Express.js framework. Something very odd is happening to a specific .ejs file where if I try to update it (like typing some mumbo jumbo in an h1 tag and then saving and restarting the server), it NEVER gets reflected in the browser no matter what I do. For example, if I delete my jumbotron, save, restart the server, and then refresh the browser, I still see the same page with the jumbotron. I also tried deleting this entire file and then restarting the server and I still see the page and it doesn't break my application which is bizarre. All other .ejs files are fine and I can see the changes that I make.
I've spent about 4 hours trying to figure this out and no one else seems to have my specific issue. I tried clearing my browser cache, using different browsers, logging in/out from Cloud9, creating a new database, going back to older versions of my code, etc. and nothing seems to be working. I'm not even sure what code to post on here since my entire app is about 2000 lines of code so far. Does anyone have any suggestions because this is really frustrating.
I've been following along with the actual MongoDB docs here
as well as several tutorial articles that are getting me absolutely nowhere.
Running a 64bit windows OS (which is a work computer, and my particular windows login is not an administrator login.. so I make sure to open any exe files as administrator). I can't do anything in the terminal beyond "mongo" or "use [db name]".
I cannot save or add anything like db.testData.insert( j ). Even typing "show dbs", I get an error that says
listDatabases failed:{ "ok" :0, "errmsg" : "unauthorized" } at src/mongo/shell/mongo.js:46
With every example I've followed, I can never seem to be "authenticated" to get past point A. Please help me! I have no idea what I'm doing wrong at this point.
UPDATE:
Sorry for the confusion, everyone. The problem turned out to be that I had an old MongoDB service still running in the background that I needed to disable.
The service must have been turned on while I was testing out some node packages or something. Once I disabled the service, everything started working as expected.
So for those of you who are having trouble, make sure you open up services.msc and make sure nothing is running MongoDB
As there isn't a formal installer for Windows, I'd recommend you delete the data folder and restart. Out of the box, there is no security in MongoDb, so you've followed a step which later requires a password. Either retrace your steps, or start over.
You don't need to switch to the admin Database. I'd suggest you instead switch to a test database for example:
> use test
switched to db test
By default, without extra configuration, on Windows you can delete the contents of c:\data\db when MongoDb isn't running (but if you're using a configuration file that specifies the dbpath, delete the contents of that folder).
There are a number of tutorials with details of how to configure users/security with Mongodb that you may want to read after you've resolved this issue.
There's little reason to create users and administrative control with MongoDB until you gain some experience with the platform. In fact, I wouldn't recommend it at all. It just gets in the way as you're seeing for no real gain.
In my j2me app that is signed by veriSign, has problem in accepting the always or yes permissions the time it has to perform PIM.getInstance().openPIMList(..) action.
When my app perform below line of code very first time of it's installation it hangs and doesn't show up the main screen rather a black background hanged screen. When I exit and restart the application it runs normally without any problem even if I delete it and put it back again and runs fine, except I delete and restart the phone and try to run it again it shows the same problem I described above.
My code of line that causes to ask permissions is here that actually also causes the problem. One more thing this error only occurs on specific phones which actually allow ALWAYS permission on start.
I am checking it over Nokia X2-05 and it shows problem but on Nokia C3-02 it doesn't as it doesn't allow ALWAYS permission automatically on start of app.
private void permissionSettings() throws PIMException {
PIM.getInstance().openPIMList(PIM.CONTACT_LIST, PIM.READ_WRITE);
}
Above is code snippet that hangs at first start.
It sounds like a bug on the handset to me, the TCK tests used to verify j2me libraries are pretty weak so lots of bugs like this find their way through.
It seems that the key is in the permissions, so I would try and play around in this area. Make sure you have the right permissions set in the .jad (before signing), if you can get hold of one try to sign with a certificate in a different security domain or certificate, try changing the permission level before running the applet.
I would expect that you'll only be able to work around the problem, so rather than suggest something specific I would be varying things within those areas.