Much thanks for both offers of DVD's its much apreciated, although it does raise the difficulty of which kind offer to chose, but I will figure that out. A comment on Russell's post regarding koganmobile, the problem with this is the data per day is limited to 400Mbytes, this means one cannot simply get large items like even a CD image. I found this type of restriction was common on monthly based accounts. Such a restriction almost never applies to prepaid data which is one of the reasons I have chosen to take that path. A point I will bring up on service selection, I will not if at all possible deal with faceless organisations, both internet service providers I deal with have real people one can talk to. I ___HATE___ organisations which go to great lengths to put there customers at arms length (ie most of them). I have found Virgin's support to be a major breath of fresh air, where organisations like Telstra apparently could not care less. Lindsay
zlinw@mcmedia.com.au <zlinw@mcmedia.com.au> wrote:
Much thanks for both offers of DVD's its much apreciated, although it does raise the difficulty of which kind offer to chose, but I will figure that out.
I'm coming a little late to this discussion. Anyone with Internode as their ISP (ADSL, not their mobile offering), can download Debian ISO images unmetered.
zlinw@mcmedia.com.au writes:
A comment on Russell's post regarding koganmobile, the problem with this is the data per day is limited to 400Mbytes, this means one cannot simply get large items like even a CD image.
I assume you've already considered and rejected simply installing from mini (12MB) or netinst (around 100MB), and then installing only what you need, on demand, via apt's http method? That would be the obvious way to do it if your installed box has reliable internet access. If you have a central host that has internet, and airgapped ones a day's travel away, you could use apt-walkabout to queue requests up over sneakernet between them. I didn't have much luck with it myself -- I found it easier to run a debmirror on the internet end, and generate monthly rsync --only-write-batch binary diffs to post out on DVD.
On 10/05/13 07:30, zlinw@mcmedia.com.au wrote:
A point I will bring up on service selection, I will not if at all possible deal with faceless organisations, both internet service providers I deal with have real people one can talk to. I ___HATE___ organisations which go to great lengths to put there customers at arms length (ie most of them). I have found Virgin's support to be a major breath of fresh air, where organisations like Telstra apparently could not care less.
Fair call. I've used some budget mobile providers, and their customer support has been terrible. Everything is fine as long as nothing goes wrong, but yeah.. when it does you're almost better off discarding the account and starting again.
On Fri, 10 May 2013, zlinw@mcmedia.com.au wrote:
A comment on Russell's post regarding koganmobile, the problem with this is the data per day is limited to 400Mbytes, this means one cannot simply get large items like even a CD image. I found this type of restriction was common on monthly based accounts. Such a restriction almost never applies to prepaid data which is one of the reasons I have chosen to take that path.
http://tinyurl.com/cgz3jvs Below is the relevant section of the above document (terms and conditions for 1-year Kogan plan). So to hit the 400MB condition you have to do it three times. Therefore you CAN download a CD image (650MB being typical, 750MB not uncommon, and 900MB the theoretical maximum) in a single day. You couldn't download a DVD image in a day, but if you use the service for anything else you wouldn't want to try and download a DVD in a month. Also note that Kogan reserves the right to "suspend, terminate or refuse to renew your Service", that doesn't mean that they necessarily will do so. Obviously they aren't going to cut off the top 1% of their customers each month even though they reserve the right to do so. # You must use the ACCESS 365 Plan in accordance with Kogan’s # Acceptable Use Policy, which allows Kogan to suspend, terminate or # refuse to renew your Service where you: # use the service for commercial use or for use as a permanent connection; # download or upload more than 400MB of data on a single day on three or more # occasions in a 30 day period; # download or upload more than 1GB of data on a single day; # or use the Service in a manner where your volume of calls or texts within a # single 30 day period exceeds the volume of calls or texts made by 99% of # users of the same type of Service within that same 30 day period, as # reasonably determined by Kogan.
A point I will bring up on service selection, I will not if at all possible deal with faceless organisations, both internet service providers I deal with have real people one can talk to. I ___HATE___ organisations which go to great lengths to put there customers at arms length (ie most of them). I have found Virgin's support to be a major breath of fresh air, where organisations like Telstra apparently could not care less.
http://tinyurl.com/c9denea It's an issue of money. According to the above the median income of people aged 15+ in Melbourne is $591 per week - $14.77 per hour if that's for a 40 hour week. http://tinyurl.com/cy47t4m The minimum wage for a 20yo is $15.59 per hour. So if there are well trained people who are aged 20+ and who are capable of getting jobs elsewhere (IE they are being paid more than the bare minimum) then they will probably cost $20 per hour or more. It's generally considered to be a good rule of thumb about corporations that the full costs of an employee (including the office, management, etc) are at least twice the wages. So you are looking at $40 per hour or more for phone calls. Even that is probably on the low side (I've worked for an ISP that paid much more than that and thought that they were getting a good deal). Then you consider that the phone operators aren't always busy, in fact if the queue is short at a peak time then there are probably lots of quiet times when hardly anyone is working. So you could double or triple the cost of the actual calls by having people on standby at idle times to cope with the peak times. So we might be talking a budget of $100 per hour or more for calls received. If you are on one of the cheaper plans (EG the $19 per month "simless" from Virgin) and they give good quality support then as little as 2 hours of support at peak times could cost the company as much as you paid for a year! -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Fri, 10 May 2013, zlinw@mcmedia.com.au wrote:
A comment on Russell's post regarding koganmobile, the problem with this is the data per day is limited to 400Mbytes, this means one cannot simply get large items like even a CD image.
If you use a 56.6K modem you'll get a theoretical maximum transfer of about 400MB per day, so some people will be in the situation of installing Debian on such a limit due to speed. Also there are a variety of 3G plans with limits of 1G per month or less so it's worth considering how to solve these problems. http://www.debian.org/distrib/netinst#smallcd The above URL has small Debian images. For AMD64 it's 221M and for i386 it's 277M which is a surprise to me, I had expected that AMD64 stuff was bigger in every way - I guess that the range of kernel binaries for i386 is causing this. So it seems that if you have download limits then you could make a saving by getting the AMD64 install CD, but then over time you would lose based on AMD64 packages tending to be slightly larger than i386. Not that size is a good reason for selecting architecture when the difference is so small. The <300M CD will allow you to do a very basic installation without accessing the Internet (I did this a while ago with a system that wouldn't connect to the Internet). Then you can use other occasions to download the other packages selecting a less than 400M subset each time. A local installation of Squid is a really good idea if you have limited bandwidth. You can set the maximum_object_size of Squid to a large value and tell it to be very aggressive in caching .deb files (which should never change so you can override all the cache settings to store them for a long time - disk is cheap). A few years ago my parents connected to the Internet via a Three 3G phone. I can't remember their quota but it was a lot less than 6G per month, maybe 1G per month. That was enough for all their regular Internet access and updating their system to the latest Debian packages. When a new version of Debian came out I would login to their system a few days before the end of the month to start "apt-get dist-upgrade", that would use all their quota for one month and the start of their quota for the next (they were on pre-paid so it didn't cost them extra). As an aside, 3G Internet access is not designed for servers (unless you pay significant extra fees) and generally doesn't allow inbound connections. The way to solve this is to have a script run "ssh -R $NUMBER:localhost:22 mothership" when the system starts up. Then on the mothership host you run "ssh -p $NUMBER root@localhost" to login to the 3G connected system. I currently run dozens of Linux servers on 3G connections and I've had a bit of practice in dealing with some of these issues. Let me know if you have any more problems with such things. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
A local installation of Squid is a really good idea if you have limited bandwidth. You can set the maximum_object_size of Squid to a large value and tell it to be very aggressive in caching .deb files (which should never change so you can override all the cache settings to store them for a long time - disk is cheap).
If the reason for installing Squid is for caching deb's then you'll be much better off with apt-cacher. Even if you want squid as a general caching solution, you'll still be better off using apt-cacher for your deb's. The reason it's better than squid is that it's smart enough to know that packages are the same packages even if you get them from different mirrors, so if you use a nearby mirror and it goes down and you have to use another, apt-cacher will still be smart enough to know if it already has a copy of some package even if it wasn't downloaded from that mirror originally. It can also intelligently discard obsolete packages (or not, if it's useful to you to have old packages kept around for whatever reason). Finally, if something broke, the packages are stored in /var/cache/apt-cacher so you can go and get them manually if required. James
James Harper writes:
If the reason for installing Squid is for caching deb's then you'll be much better off with apt-cacher.
I've had bad experiences with the two older apt-specific partial repo caching tools (apt-cacher and another one, I forget the name); IIRC they were vulnerable to injection from the LAN, and this would regularly happen by accident if >1 distro was used (e.g. ubuntu and debian both had foo-1.0-1 but with different checksums). IIRC last time this came up, a new one had recently come out (apt-cacher-ng?) which somebody said fixed all the problems. I switched to debmirror for my own needs, and it has worked flawlessly. Obviously it's not an option for the OP -- IIRC it typically pulls down a couple of hundred MB per week. Agree that apt-cacher or similar is easier and smarter than trying to replicate functionality in squid.
James Harper writes:
If the reason for installing Squid is for caching deb's then you'll be much better off with apt-cacher.
I've had bad experiences with the two older apt-specific partial repo caching tools (apt-cacher and another one, I forget the name); IIRC they were vulnerable to injection from the LAN, and this would regularly happen by accident if >1 distro was used (e.g. ubuntu and debian both had foo-1.0-1 but with different checksums).
Thanks for the tip. I've only ever used Debian but had thought about trying Ubuntu.
IIRC last time this came up, a new one had recently come out (apt-cacher-ng?) which somebody said fixed all the problems.
I did see an apt-cacher-ng recently. I wonder if the repository can migrate... James
Russell Coker <russell@coker.com.au> writes:
As an aside, 3G Internet access is not designed for servers (unless you pay significant extra fees) and generally doesn't allow inbound connections. The way to solve this is to have a script run "ssh -R $NUMBER:localhost:22 mothership" when the system starts up. Then on the mothership host you run "ssh -p $NUMBER root@localhost" to login to the 3G connected system.
That can hit TCP-in-TCP resend fights. ssh -w/-L/-R useful for ad-hoc infrastructure, but recommend openvpn instead for long-term, permanent setup. Also had problems in field with ssh -w dying when either end dies; autossh was suggested as fix but it felt icky; switching to openvpn was easier. ipsec probably also good choice.
On Sat, 11 May 2013, "Trent W. Buck" <trentbuck@gmail.com> wrote:
Russell Coker <russell@coker.com.au> writes:
As an aside, 3G Internet access is not designed for servers (unless you pay significant extra fees) and generally doesn't allow inbound connections. The way to solve this is to have a script run "ssh -R $NUMBER:localhost:22 mothership" when the system starts up. Then on the mothership host you run "ssh -p $NUMBER root@localhost" to login to the 3G connected system.
That can hit TCP-in-TCP resend fights.
I don't believe that ssh -L/-R will do that. In such a configuration I don't think you have TCP packets tunnelled in ssh (in the normal case ssh isn't running as root and I don't believe it has the ability to do that if it wanted to).
ssh -w/-L/-R useful for ad-hoc infrastructure, but recommend openvpn instead for long-term, permanent setup.
Masquerading a TCP connection is a lot easier than doing so for a UDP connection and I think it's more likely to be done correctly. Using TCP for OpenVPN causes the TCP-in-TCP problems you reference.
Also had problems in field with ssh -w dying when either end dies; autossh was suggested as fix but it felt icky; switching to openvpn was easier.
I haven't tried ssh -w. But ssh -R works well for me on many systems on the Telstra NextG network. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker wrote:
[ssh -R] That can hit TCP-in-TCP resend fights.
I don't believe that ssh -L/-R will do that. In such a configuration I don't think you have TCP packets tunnelled in ssh (in the normal case ssh isn't running as root and I don't believe it has the ability to do that if it wanted to).
Ah, I think you may be right -- in which case my point is moot, as it applies only to -w. Sorry for the noise.
Hello All, On Fri, 2013-05-10 at 07:30 +1000, zlinw@mcmedia.com.au wrote:
Much thanks for both offers of DVD's its much apreciated, although it does raise the difficulty of which kind offer to chose, but I will figure that out.
Whomever, may I request a set of DVD's, I am on a 56K modem. Let me know and I will try to sort out blank disks and postage if reasonable. My responses may be delayed if my work involves early starts and long days.
A comment on Russell's post regarding koganmobile, the problem with this is the data per day is limited to 400Mbytes, this means one cannot simply get large items like even a CD image. I found this type of restriction was common on monthly based accounts. Such a restriction almost never applies to prepaid data which is one of the reasons I have chosen to take that path.
Since there are times I desire to get larger items, I am following this with interest. As to with whom, price and effective coverage are significant issues. Telstra is the real option, except I dislike assisting their management salary packages.
A point I will bring up on service selection, I will not if at all possible deal with faceless organisations, both internet service providers I deal with have real people one can talk to. I ___HATE___ organisations which go to great lengths to put there customers at arms length (ie most of them). I have found Virgin's support to be a major breath of fresh air, where organisations like Telstra apparently could not care less.
It would help if all providers would acknowledge that Linux is standards compliant at the networking level. I want real support for the connection. What I have to do to achieve the result is up to me. I do not expect to need to be told how, just what. Currently, Telstra will not provide "support" for Linux, including the simple link metrics. Regards, Mark Trickett
participants (8)
-
James Harper -
Jason White -
Mark Trickett -
Russell Coker -
Toby Corkindale -
Trent W. Buck -
trentbuck＠gmail.com
-
zlinw＠mcmedia.com.au