October 2014 - openSUSE Users - openSUSE Mailing Lists

Re: [opensuse] Loosing tabs in firefox
by John Perry 04 Oct '14

04 Oct '14

On 10/4/2014 16:33, Bob Williams wrote: > To make a vowel short, you follow it with a double consonant, eg > flossing, popping, hopping, loss. > > So super = to an extreme degree > supper = an evening meal. > > It's more difficult with lose and loose, as both have a long sounding > 'o'. Different roots. Wow! another old-timer who was taught English before the fools at UC Berkeley decreed that spelling and grammar were no longer relevant to the English language :-). Now I'll shut up, too. john perry (yes, I know...) -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] rsync for incremental/synchronization ... 2-way, three-way?
by Anton Aylward 04 Oct '14

04 Oct '14

Can I do a simple 2-way sync? I have PDFs and ebooks on various devices, tablets, phones and desktop. All 3 need to be kept in sync. And perhaps with a master copy backed up to the cloud? Has anyone done this? I've tried googling but while there's a lot of interesting stuff and I do know about 'diff' and kdiff3, but over the network? -- Most of what we call management consists of making it difficult for people to get their jobs done - Peter Drucker -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 4

[opensuse] a broad appeal to fix opensuse's package-management's repository/redirector failure & recovery mechasnism
by grantksupport＠operamail.com 04 Oct '14

04 Oct '14

In my experience, package management's routine failure to find/use a 'healthy' repository is a long-standing production problem. I'm requesting a fix. Here's a summary: I run Opensuse 13.1 on numerous machines lsb_release -rd Description: openSUSE 13.1 (Bottle) (x86_64) Release: 13.1 Current count is ~200. The machines are installed at multiple locations around the globe. They're connected to the 'net via a variety of different networks providers. Some of the machines are directly connected to the 'net, some are behind LAN routers, switches & firewalls. Package management for all of the machines is handled exclusively via zypper cli. Each machine has a common core of repositories defined in /etc/zypp/repos.d, and frequently has a number of additional @openSUSE dev (!'home') repos defined. In ALL cases, the default install of repos sets have been installed with the meta-director as baseurl, baseurl=http://download.opensuse.org/... Regular package maintenance consists of zypper clean --all zypper (d)up The maintenance frequency is nominally 1/wk, often 1/dy, and in devs' cases, often more frequent. In virtually ALL cases, the update process regularly fails @ retrieving/refreshing the repos' (meta)data. For example, a typical result is: ... Checking whether to refresh metadata for KDE4-Extra-Unstable Retrieving: repomd.xml .......................................................................................[error] File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Current_…' Abort, retry, ignore? [a/r/i/? shows all options] (a): ... This occurs occassionally for any/all repos, whether the standard distribution repos (security, update, etc), core DM (e.g. KDE*) additional repos, or the more 'esoteric' !home OBS-hosted repos (e.g., security:netfilter). The failure rate for overall update/upgrade process attempts is, very roughly, ~15%. The error is NON-recoverable. 'Abort' & 'retry' *never* work. Chats @ IRC re: the issue typically result in the same '(non)responses' : "wait", "works for me", "prove it", etc. The ONLY solution(s) that work are: (1) wait some random amount of time -- typically hours, occassionally days -- until the system magically heals itself, (2) visit the download.opensuse.org link for the repo, click 'details' for a target page, identify a specific working/available repo for the package(s) of interest, and manually edit baseurl= for the problematic repo. Neither is tenable for a reliable operating environment. It is simply unmanageable in either a single, local or widely-distributed environment. (2) is further confounded by the fact that, at any given time, a previously-working, manually-selected repo may, itself, fail, requiring -- yet again -- another manual intervention. Within the scope of our environment, no other distro's package management system has anywhere near the failure rate demonstrated here. (We've ~600+ other machines running a mix of Centos, Fedora, Debian & Ubuntu). This has been occurring for literally years, across multiple openSUSE versions, and remains unaddressed. I know, without any doubt, that others experience similar/frequent failures -- it's been a frequent discussion with our partners, as well as in openSUSE* IRC channels. This needs a fix. As to what, specifically, that fix can/should be -- I'm unclear. If a solution already exists, I'm unaware. One idea -- a fallback mechanism *within* a repos' definition would be useful For example, allow in a given repo's def'n, having multiple, numbered baseurls baseurl1=http://direct/url/to/specific/site/1/... baseurl2=http://direct/url/to/specific/site/2/... baseurl3=http://download.opensuse.org/... ... baseurlN=http://direct/url/to/specific/site/3/... and add fuction to zypper so that for each repo, the baseurls would be tried in order for any given failure. By adding, e.g., a failcount2abort=X to either/both a given repo's defn, or /etc/zypp(er).conf, the overall process could be terminated if there were "X" # of subsequent fails, indicating a likely systemic problem requiring further intervention. I'd appreciate hearing from "those responsible for keeping the redirector & repos working" re: * acknowledgement, or refusal thereof, of the failure issue * clarification as to why it occurs in the first place * ideas/suggestions as to what can/should be done to fix it Thanks. Grant -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

6 12

[opensuse] test
by Hans Krueger 03 Oct '14

03 Oct '14

test -- Hans Krueger hanskrueger007(a)roadrunner.com registered Linux user 289023 -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] Linux and multicast
by James Knott 03 Oct '14

03 Oct '14

As an experiment, I tried pinging 224.0.0.1, which is the all hosts multicast address, which all hosts are supposed to respond to. When I do that, I only get a response from my Yamaha A/V receiver. Other devices, including computers running Linux and Windows 7 do not respond. I get the same results if I ping the local network broadcast address, only the A/V receiver responds. Given that all devices are supposed to respond, does anyone know why Linux or other devices don't? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 7

Re: [opensuse] Linux and multicast
by James Knott 03 Oct '14

03 Oct '14

On 10/03/2014 11:24 AM, Hans Walter Finckh wrote: > they should respond the regular ping any ping You give with any > parameter coz ping is a TCP/IP based command. > if not, you can do it the other way or send a ping from a dhcp-server > if there is one Yes I know they should respond. My question is why only the one device responds to the mulitcast, local broadcast or broadcast addresses. In IPv4, 224.0.0.1 is an address all devices should respond to. Why are they not? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 7

Re: [opensuse] Linux and multicast
by James Knott 03 Oct '14

03 Oct '14

On 10/03/2014 02:23 PM, Hans Walter Finckh wrote: > yes, broadcaste cause a lot of trafic overhead and so decrease the > overall bandwith, and the pace, we all are on the way:-D There is still a need to address various classes of devices. That's why IPv6 uses multicasts to groups such as all hosts, all routers etc., in addition to things like multimedia streams, which actually reduce bandwidth by not having to duplicate the stream to all listening devices. While multicasts are used on IPv4, they weren't used to their potential as multicasts were an afterthough, replacing the old class D address block. On the otherhand, multicasts are an integral part of IPv6 operation. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

Re: [opensuse] Linux and multicast
by James Knott 03 Oct '14

03 Oct '14

On 10/03/2014 12:08 PM, Brandon Vincent wrote: > Most devices will not respond to broadcast pings to prevent from being > utilized as part of a smurf attack [1]. > > You can temporarily turn this off on a Linux machine by issuing, "echo > "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts". That appears to do it for multicasts, broadcasts and multicasts. However, broadcasts from outside the network should be blocked by the routers to prevent that attack. But multicasts and local broadcasts should still work, as happens with my A/V receiver. Is perhaps that setting a bit too agressive in blocking multicasts and local broadcasts, in addition to broadcasts? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 1

[opensuse] autoyast - what is the option to enable the pause before the first reboot?
by Per Jessen 03 Oct '14

03 Oct '14

$SUBJ says it all. /Per -- Per Jessen, Zürich (16.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 4

[opensuse] outgoing tcp connections are limited to 200 kb/s, how to fix?
by Robin Roth 02 Oct '14

02 Oct '14

Dear all, since a reboot about two weeks ago, on a server I use, all outgoing tcp connections are limited to about 200 kb/s. Incoming tcp and udp both ways is fine (1 GB/s) and also when using multiple connections simultaneously higher bandwidths can be reached. The server is running 12.3. The problem appears with apache, but also when testing with iperf. There is only one switch in between my machine and the server and switching the port with other machines doesn't help. Things I already tried: - disabling susefirewall, completely empty iptables - check tc (shows no entries) - playing around with tcp buffers, like discussed at https://fasterdata.es.net/host-tuning/linux/ - reboot :) Do you have any suggestions what could be the problem? Thanks, Robin

5 4