I've noticed that cloning repo via ssh is much slower than through http regardless if it is from my own servers or BitBucket. Much in my case equals to 10 seconds from http vs. more than 2 minutes with ssh on the same BitBucket repository.
I'm using Mercurial on Windows (TortoiseHg 1.5, Mercurial 1.7). Both tests were done from GUI as well as from CLI.
Is it a common "issue" or I'm doing something wrong?
Have you turned on ssh compression in your ssh client?? It's on by default in HTTP, but it's off by default in ssh it's a setting that ssh and not mercurial controls.
http://confluence.atlassian.com/display/BITBUCKET/Using+SSH+to+Access+your+Bitbucket+Repository#UsingSSHtoAccessyourBitbucketRepository-EnablingCompression
Usually Mercurial ssh access is faster than http -- it is for me anyway.
I find that on a LAN things are faster without compression (compression takes more time than xfer) and on a WAN it's the reverse.
I have seen the same.
At first, I had a RHEL4/RHEL5 ssh issue, that prohibited compression to be negotiated - but that's fixed now (configuration tweaks). Unfortunately, I still see a factor of ~3 in cloning a repo (http vs. ssh).
I used "ssh = ssh -C -v" to see the compression ratio.
I'm using Linux, and I see this when cloning a large repo (180M+) - over a WAN (Europe <-> India/Asia).
Related
I have 2 server at which I am working locally. The first is a front-end in Vuejs, and the second is back-end in Flask. From the client I request an api to the second.
I have to upload these two on a remote Linux VM (Debian), for which I have credentials and I can successfully connect it via PuTTy.
How do I transer my 2 directories to the VM?
Then, I should change the address that the client uses for api requests of the server, that is all? Or I will have to do something else?
You can copy directories by the scp or sftp protocol. In your case, this can be done most easily by the winscp software.
Both scp, sftp (implemented by winscp) and ssh (implemented by putty) use the ssh protocol. Putty is for remote terminal (i.e. you can give commands to the server), while winscp uploads, downloads and manages files on it.
If you are developing something, it is likely that you will need to this deployment more regularly. These softwares are only good for single-time deployments. In professional environments this deployment is automatized and happens quickly.
It is very likely that you also have some database in your project. Here the most common options are either some db-level synchronization, or dumping the database into files and synchronizyng on the file level. But it is already another topic.
It is also unlikely that you will need two different VMs for the vuejs and for the flask. You could wire them together to a single VM, that would make your task far more easy.
You will likely have a hard time to make your deployment on your server well working. This all is just the beginning. But don't worry, after you've learnt it all, it will be easy!
I am getting the connection time out when running the command in bootstrap.
Any configuration suggestions on networking part if I am missing
It’s says kubernetes api calling time out
This is obviously very hard to debug without having access to your environment. Some tips to debug the OKD installation:
Before starting the installation, make sure your environment meets all the prerequisites. Often, the problem lies with a faulty DNS / DHCP / networking setup. Potentially deploy a separate VM into the network to check if everything works as expected.
The bootstrap node and the Master Nodes are deployed with the SSH key you specify, so in vCenter, get the IP of the machines that are already deployed and use SSH to connect to them. Once on the machine, use sudo crictl ps and sudo crictl logs <container-id> to review the logs for the running containers, focussing on the components:
kube-apiserver
etcd
machine-controller
In your case, the API is not coming up, so reviewing the logs of the above components will likely show the root cause.
I'd like to access the git commit hash and tag, say using git describe, but the openshift virtual machines seem to have no git repository (readable by me anyway).
Is there any way to access this information using the openshift deployment hooks? I'd like to be able to have each instance log the version (ie tag/commit hash) it's running.
At the moment, my best option seems to be to write a deployment script, and use rhc scp to push the version string to the server, but it feels a bit hacky.
Thanks!
I'm trying to use a Centos VPS as a place to host my mercurial repositories, I'll init these repositories on the server and then clone them to my local computer using TortoiseHG.
I've setup a clean VPS with Centos 6 and taken the usual security steps such as root login disabled, changed ports, ssh key access only and a new user user123.
I connect to the server using pageant and ssh keys generated using puttygen.
I've setup a virtualhost that's only accessible to my local machines ips that's located at /var/www/vhosts/hg/ all of my repositories are then accessible using http://123.123.123.123/repositoryname/
I've used yum install mercurial and can create repositories using hg init.
I can then succesfully clone my repositories to a local machine using the above url.
The problem
So far so good, however the issues arise when I try to push. At the moment I've not setup any sort of connection I'm just simply going on that I've been able to clone so I should be able to push (moronic).
However when I do try and push I get the following error from TortoiseHG:
abort: destination does not support push - command returned code 255
How do I go about adding support to be able to push to the above server configuration? Should I try and get it to use pageant or do I need additional server software so support pushing?
I'm not really sure of what the next step is and Googling hasn't yielded any success.
all of my repositories are then accessible using http://123.123.123.123/repositoryname/
Bad configuration... and probably totally wrong idea of using http, when you have ssh
Which http-frontend do you use?
Did you integrate (any) frontend with Mercurial?
Have you push enabled?
In case of ssh://-served repositories your task may be a lot simpler
My problem is quite simple
I'm behind agressive proxy, firewall and every known human way to make a developer's life miserable and I cannot clone a repository from Google Code or any other sort of online repository for that matter.
Question, Is there an online tool that allows me at least cloning a mercurial repository without having to access using non http protocols?
I doubt you'll be able to get around your network's restrictions with just a tool on your university machine.
I asked a sysadmin friend about this, and together we came up a few ideas. These are all rather vague because there really isn't enough information about the university network to give a clear-cut solution. However, they all require the help of another machine outside of the university network. Well, almost all of them.
Fork it
It may be possible to set up a repository and server on a computer outside that network that allows http for pulling, especially if you already know which projects you want to clone. You can setup a scheduled job to pull from the original repositories to keep the forks up to date.
If the university network is only blocking port 443 communication rather than the https protocol itself and you can only setup the forking server for https, you can configure it for a port other than 443 such as 8080, and since this web server is special-purpose you could even make it port 80.
Tunnel around
SSH, Telnet, Remote Desktop. Some repositories allow connections in addition to https, such as ssh. Not many that I've seen, though. But if the university network is not blocking certain remote connection protocols, you may be able to use one of those to connect to a computer outside the network and clone/pull to that machine and then to yours at the university. Or at the very least, copy it once you've cloned it.
Air beats fire
AKA Sneakernet. Clone them to portable storage outside of the university and carry it with you. Then plug it into the university computer and clone from there. There is a noticeable lag time, mind you.
Other storage variations probably exist as well, such as if the university gives you network storage space you can access outside of that network. You could zip the repository and upload it to that.
Machiavelli
Orchestrate events and manipulate people so that the sysadmin is replaced by a competent sysadmin who will lift the draconian, asinine measures that are currently in place. The other options are probably much easier. And safer.