My source code server has been infected ransomware and when I want connect to the VisualSVN via Tortoise SVN the following message is displayed :
VisualSVN runs without any problems and Everything(All users, Repos, Branches, Trunks and and so on) is displayed in the VisualSVN server and I can even create a new Repo But I can not connect to it via Tortoise SVN.
This problem continues even after VisualSVN service restarted.
Is there a solution to this problem?
The error tells that the access to the repositories is forbidden. I guess that the virus you caught made modifications to user access rules lists or made them unavailable.
has been infected ransomware
Repair your server or restore the data from backup. And don't forget to ensure that this will never happen in future.
Related
Essentially, I'm trying to build a web server on my home desktop.
However, I find that I am out and about quite often, so it would be nice to be able to use my laptop to edit the code on GitHub, push it to the cloned repository on my home computer, and restart the server with the changed code.
I'm building a node.js server, so all I have to do to run it is type git pull and then node app.js into the bash terminal.
I'm basically wondering if it is possible to use a different computer to execute those commands remotely.
One constraint is that although my desktop can install any software required, my laptop cannot due to a lack of administrator permissions (it's a school-issued laptop).
Also, I run windows 10 home, so enabling RDP is nearly impossible or laggy at best.
If possible, it would be nice to do the pushing to my desktop via the GitHub site. Is it possible?
It would be nice to do the pushing to my desktop via the GitHub site.
All you can do "via the GitHub site" is declared a webhook on push event.
That webhook can send a push payload on any IP you want.
If your laptop can exposes a public IP (or has a secure tunnel to localhost) with a listener (like that npm listener), it can ben notified and pull from the GItHub repo whenever there is a push.
I have a site when I tried to apply local staging it's worked fine,but we I tried to connect it through remote server it's not working giving error connection can't be established.Does any one tried it?
This is the configuration with the error message:
This blog post (disclaimer: my own) explains how to do it with https - you can omit long parts of it if you don't want encryption. It also covers 6.0, but the general principle is still the same.
You want to pay special attention to the paragraph Allow access to webservices in that article and check if your publishing server (the "stage") has access to the live server. In general, if this is not on localhost, it requires configuration as mentioned in that article.
As you indicate that you can't connect to your production server from your staging server, please check by opening a browser, running on the staging server and connect it to the production server - go to http://production-server-name:8080/api/axis and validate that you can connect (note: You get the authoritative result for this test only when not accessing localhost as the production system: Do run the browser on the staging system!) - with this test you can eliminate the first chance of your remote system being disallowed. Once this succeeds, you'll need credentials for the production server to be entered on the staging server - the account that you use needs to have permissions to change all the data it needs to change when publishing content (and pages etc.)
The error message you give in the added screenshot can appear when the current user on staging does not have access to the production system (with the credentials used) - verify that you have the same user account that you are using on your staging system (the one that gets the error message from the screenshot) in your production system. Synchronize the passwords of the two.
I your comment you give the information that you're using different version for the staging and the production environment - I don't expect that to work, so this might be the root cause. Test with both systems at the same version.
A couple important points to keep in mind with remote publishing:
If you're not on LDAP (or you have different LDAPs for different environments), you should validate that your user account is exactly the same in both source and target environments. So, if you're on the QA site and you want to remote publish to production, your screen name, email address, and password should all be the same.
Email address is uber important. Depending on which distribution (version) of Liferay you are on, the remote publish code uses your email address to irrespective of whether or not you have portal-ext.properties configured to use screenname.
You should have the Administrator role in on both sides. It may not be required in every scenario, but giving that role out to users that do remote publishing has saved me time and effort debugging why someone's remote publish didn't work. Debugging this process takes a very long time.
If remote publishing is causing you problems (and it probably is or you wouldn't be here), try doing lar file exports / imports. This is important since remote publish failures are not exactly helpful in telling you what failed, they just tell you then failed. Surprisingly, there are often problems in the export process and you can sometimes pinpoint some bad documents or a funky development thing you did using Global scope and portlet preferences that caused your RP to fail. I generally use this order in this situation a) documents and media [exclude thumbnails or your lar file will likely double in size, also exclude ranks if you're not using them] from the wrench icon in the control panel b) web content from the wrench icon in the control panel c) public pages [include data > web content display, but remove all the other data check boxes], include permissions, include categories d) private pages [same options as public pages].
If you already have Administrator role and it's saying you don't have permissions to RP to the remote site, setup your user on the target environment with the "Site Administrator" or "Site Owner" role.
A little late for first and foremost, but anytime you have something that's not working (remote publishing or otherwise), check the logs before you do anything else. The Liferay code base doesn't include a lot of helpful logging, but you do occasionally get a nugget of information that helps you piece together enough to do root cause analysis.
Cheers! HTH
I got a backup of a Sharepoint 2010 site that I created from our client's production server so that I can make some new changes to it on my staging server.
I can restore the site collection from the backup without a problem but when I try to create a backup of the same site on my staging server, I always get the error "Operation is not valid due to the current state of the object".
Before the error is given however, a small part of the backup file is created. If I try to run the Backup-SPSite again, it always fails at the same point and the corrupt backup files are always the same size.
Going through the logs it looks like the problem might be related to user permissions. I wonder if it's possible that the user permissions, user data, etc that came over from the client's production server are somehow screwing the backup process now because the same data cannot be found on my staging server.
The same error is mentioned here http://technet.microsoft.com/en-us/library/ee748617.aspx but UseSqlSnapshot parameter doesn't work anyway in my case.
I've been hitting my head against the wall with this problem and would appreciate if anyone has any advice on what might help! :)
The setup:
Windows Server 2008 R2
Sharepoint 2010 Server (no SP1 because it hasn't been installed on the client's production server)
Microsoft SQL Server Express Edition
Cheers!
The backup process started working after I checked in a file that had been checked out by a user on my client's production server.
I found out what file that was by opening the corrupted backup file and looking at the title of the last entry.
I've got hgweb up and running on II7 7 (on windows server 2008). The web interface works, and I can view, pull, and clone the repositories there. But I cannot push, doing so gives me a 502 error right after "searching for changes". Using --debug shows the last few lines as:
sending unbundle command
sending 622 bytes
HTTP Error: 502 (Bad Gateway)
I am using TortoiseHG to push, but the result is the same when using the mercurial command line.
I had followed the tutorial here: http://www.sjmdev.com/blog/post/2011/03/30/setting-mercurial-18-server-iis7-windows-server-2008-r2.aspx to setup hgweb.
Looks like an old question but someone is bound to come across it again. I was close to drawing a black circle on a wall and ... anyhow the issue for us was the way central repository was created. We cloned it from BitBucket while being Remote connected to the machine as local administrator.
The issue was in [Repository].hg folder. You need to set correct permissions on it. Try it with adding Everyone -> Full permissions for test purpose. Please make sure you change this to a dedicated network login or appropriate local account afterwards.
I was seeing the exact same behaviour - even push worked fine with exception of getting a Bad Gateway after all the time. After correct permissions were set the issue was gone.
Thinking about it now, probably the best solution is to add each network login that uses the repo to machine users and then set up access permissions to .hg folder to local users.
Hope it helps someone.
Try using the ISAPI module method instead of the CGI that executes phython.exe as documented here. There's also another related, and possibly duplicate question here as well.
Take a look at the 'Push_ssl' setting in your hgweb.config file.
I was getting the same error (had mine set to '*'), and was able to resolve it by removing the line entirely. Granted, this makes Mercurial somewhat less secure, but it lets me get by the configuration issue (for now) while I investigate properly configuring SSL on the server.
You may also have to review the 'Allow_push' setting in order to get past further errors (or take another look at your authorization).
NOTE: At least in my case, having 'push_ssl = false' wasn't enough as that resulted in further errors (authorization failed).
(Again this is simply a temporary solution until the server can be properly secured.)
It could happen by different reasons, to get more details about the error run
hg push --config ui.usehttp2=true --config ui.http2debuglevel=info
For example, problem may occur because of proxy server or just in case when the Mercurial Web Server "forgets" about repositories it needs to serve: in case if you are using TortoiseHg workbench go to Workbench UI, Repository -> Start Web Server, make sure that your repository is in the list of the served repos.
Try use https instead http in .hg/hgrc, I have resolve this problem for code.google.com.
I had this issue, and the problem ended up being the server running out of disk space.
All of a sudden, I'm getting the following message in the area where
my remote files used to be listed:
"To see the files in your repository you must define its Version
Control settings."
This is happening for multiple sites and the Version Control setting
is set to none (and it always has been).
I had another Dreamweaver author, try it on her system and she got to the remote server just fine. When I logged on to her system I got the same problem, but this time it said "FTP error...password problem..."--she's on Windows 7--I'm on XP. Our company does not support "version control." I can't find any "SVNs" lieing around either.
You will see this message when you are in the 'Repository View' and you haven't set up version control. You can check this in the FILES tab/window. If you don't see it press F8 or select Window/Files. Switch from Repository view to Local View, Test Sever, or Remote Server as appropriate.