Bug#1051983: ITP: golang-github-katalix-go-l2tp -- L2TP and PPPoE tools built using the go-l2tp package
Package: wnpp Severity: wishlist Owner: Tom Parkin X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-katalix-go-l2tp Version : 0.1.1 Upstream Contact: Tom Parkin * URL : https://github.com/katalix/go-l2tp * License : BSD Programming Lang: golang Description : L2TP and PPPoE tools built using the go-l2tp package go-l2tp is a suite of Go libraries for building L2TP applications on Linux systems. . It includes a set of daemons for managing various related connections: * kl2tpd is a client (LAC-mode) L2TPv2 daemon, * ql2tpd manages static L2TPv3 Ethernet connections, * kpppoed is a PPPoE server daemon which can be used alongside kl2tpd to implement L2TP Access Concentrator connections. . The go-l2tp daemons use the Linux kernel L2TP and PPP subsystems for data transport. PPP termination is delegated to pppd. Since go-l2tp's initial release on GitHub, the NetworkManager-l2tp project (a VPN plugin for NetworkManager), has adopted kl2tpd as its default L2TP daemon, falling back to xl2tpd if kl2tpd is not available. kl2tpd offers several benefits over xl2tpd, including the use of ephemeral ports by default, and supporting the use of IPSec with kernel-mode L2TP data transport. Offering kl2tpd as a part of a Debian package will make NetworkManager-l2tp easier to maintain and make it easier for users to use kl2tpd for their VPN connections. As a golang package, golang-github-katalix-go-l2tp would fall under the aegis of the Debian Go Packaging team. However the upstream authors would be happy to provide collaborative ongoing support with the maintenance of the package.
Bug#971602: ITP: trojan-go -- A Trojan proxy written in Go. An unidentifiable mechanism that helps you bypass GFW.
Package: wnpp Severity: wishlist Owner: Tom Yang X-Debbugs-Cc: debian-devel@lists.debian.org, wyh.aa...@gmail.com * Package name: trojan-go Version : 0.8.2 * URL : https://github.com/p4gefau1t/trojan-go * License : GPLv3 Programming Lang: Go Description : A Trojan proxy written in Go. An unidentifiable mechanism that helps you bypass GFW. trojan-go is a much more functional and easier to configure proxy tool than the original Trojan. It supports WebSocket over TLS/SSL, router modules, and multiplexing for better performance.
Re: A little "research" on nvi given the vim-tiny issue
On Thu, Mar 19, 2020 at 12:35 AM James McCoy wrote: > On Wed, Mar 18, 2020, 17:29 Tom H wrote: >> >> PPS: Gentoo's vim[minimal] is vim configured using >> "--with-features=tiny" like Debian's vim-tiny. > > Debian's vim-tiny actual uses "--with-features=small". We used to, > back in 2007, build a hybrid between small and tiny, by configuring > the tiny feature set and then enabling extra features. However, that > became too brittle to maintain and now most, if not all, of the > features we were enabling are enabled by default upstream. Sorry and many thanks. I assumed that "tiny" meant "tiny" :(
A little "research" on nvi given the vim-tiny issue
Russ A said [1] that nvi "is orphaned both upstream and in Debian". I wanted to emphasize that fact by pointing out that Gentoo's removing nvi for similar reasons, and trying to install it just now resulted in this "package.mask" message: $ sudo emerge -p nvi # Michał Górny (2020-02-17) # Based on very old code needing a lot of patches. Minimal upstream # activity since early 2011, last patches accepted in 2016. Multiple # unresolved bugs. app-editors/vim[minimal] is the recommended # replacement. # Removal in 30 days. Bug #690102. Arch uses "the traditional vi" [2], AFAICT, it was last released in 2005 and Arch has three patches for it. Arch's AUR has nvi from [3] version 1.79 and nvi-multibyte-upstream from [4] version 1.81. The three BSDs use nvi as "/usr/bin/vi". The READMEs indicate that FreeBSD has version 2.1.3, NetBSD has version 1.80, and OpenBSD has version 1.79. Version 1.81 has multibyte support and Debian and Gentoo use it. FreeBSD's version 2.1.3 is the result of a GSoC to add multibyte-encoding support [5]. That's when it jumped from 1.79 to 2.1.1. [1] https://lists.debian.org/debian-devel/2020/03/msg00243.html [2] http://ex-vi.sourceforge.net/ [3] https://sites.google.com/a/bostic.com/keithbostic/vi/ [4] https://repo.or.cz/nvi.git [5] https://github.com/lichray/nvi2 PS: Fedora's vim-minimal is vim configured using "--with-features=small". PPS: Gentoo's vim[minimal] is vim configured using "--with-features=tiny" like Debian's vim-tiny.
Re: concerns about Salsa
On Tue, Jun 5, 2018 at 2:37 PM, Pierre-Elliott Bécue wrote: > Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit : >> >> In practice, I have found that it is much easier to deploy a >> production service directly from its git tree. This makes it much >> easier to make changes. > > I've always found otherwise, ie that packaged stuff makes the > administrator of a service spare a lot of time. > > I wonder then, if a lot of people prefer deploy a service from > upstream's git repo/cookbooks, what is the purpose of packaging? Who > would benefit from it and who should use package-distros? In this case, isn't it because the service is being installed as and run by user "git"?
Reminder: Outreachy mentor application period closes September 17
All: We already have some great projects and mentors listed on: https://wiki.debian.org/Outreachy/Round15 But we could use more! Please consider becoming a mentor and add your project ASAP! Thanks, --Tom
Bug#871913: ITP: boot-clj -- Build tooling for Clojure
Package: wnpp Severity: wishlist Owner: Tom Marble * Package name: boot-clj Version : 2.7.1 Upstream Author : Alan Dipert * URL : https://github.com/boot-clj/boot * License : EPL Programming Lang: Java Description : Build tooling for Clojure Boot is a Clojure build framework and ad-hoc Clojure script evaluator. Boot provides a runtime environment that includes all of the tools needed to build Clojure projects from scripts written in Clojure that run in the context of the project. This package will be maintained by the Debian Clojure Team.
Bug#871781: ITP: shimdandy -- Shim wrapping multiple Clojure runtimes into the same JVM
Package: wnpp Severity: wishlist Owner: Tom Marble * Package name: shimdandy Version : 1.2.0 Upstream Author : Toby Crawley * URL : https://github.com/projectodd/shimdandy * License : EPL Programming Lang: Java Description : Shim wrapping multiple Clojure runtimes into the same JVM A Clojure runtime shim, allowing for multiple Clojure runtimes in the same JVM. Clojure has a static runtime (implemented as static methods off of clojure.lang.RT), so to run multiple runtimes in the same JVM, they have to be loaded in isolated ClassLoader trees. ShimDandy provides a mechanism for isolating the runtimes within a non-Clojure application, and for calling in to the runtimes from the app. This library is a dependency for the Clojure build tool 'boot' and will be maintained by the Debian Java Team.
Re: Naming of network devices - how to improve it in buster
On Fri, Jul 14, 2017 at 10:20 AM, Henrique de Moraes Holschuh wrote: > On Fri, 14 Jul 2017, Tom H wrote: >> The classic naming scheme for network interfaces applied by the kernel >> is to simply assign names beginning with "eth0", "eth1", ... to all >> interfaces as they are probed by the drivers. As the driver probing is > > Unfortunately, this is incorrect. It's most likely written by Lennart so you should take it up with him. > MOST PCI/PCIe NICs indeed use "ethX", etc. But the naming scheme really > is device driver-specific, and the "default" name used by a driver is > considered part of the kernel stable ABI, and cannot be changed on the > kernel side unless it is done opt-in at kernel config time (kconfig) or > at boot time (kernel command line, device tree, etc). > > That said, most consumer devices nowadays are handled by drivers that > will use either ethX or wlanX by default. > >> generally not predictable for modern technology this means that as soon >> as multiple network interfaces are available the assignment of the names >> "eth0", "eth1" and so on is generally not fixed anymore and it might >> very well happen that "eth0" on one boot ends up being "eth1" on the >> next. > > Correct, in the general case.
Re: Naming of network devices - how to improve it in buster
On Thu, Jul 13, 2017 at 6:14 AM, Russell Stuart wrote: > On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote: >> >> Stateless "/etc". >> >> Systems with multiple NICs where the order in which they're >> recognized by the kernel can vary. > > I asked for a person. You raised more than one point. I was replying to "I still don't understand what use case the current scheme is aimed at." I don't know of a person who types the weird new names. I rename all my NICs "enX". But I don't think that many people end up with the "en48e244f61c1b" that you mentioned (it would anyway be "enx48e244f61c1b" not "en48e244f61c1b"). I'd expect the more common variants to be "enoX", "ensX", and "enpXsY". > I guess I really asking for a use case. > "Stateless /etc" isn't either. Why isn't "stateless /etc" a use-case?! Red Hat controls udev development. It or its customers might want to have such systems. > I've never seen the kernel vary the order it enumerates a PCI bus. It's happened to me. It's happened to ex-colleagues. When there isn't a file under "/etc" to map NIC name to NIC MAC address. > This isn't an accident. Quoting "According to: "PCI Express System > Architecture" R. Budruk, D. Anderson, T. Shanley, ADDISON-WESLEY > DEVELOPER´S PRESS, 2003. ISBN: 0-321-15630-7, page 743": > > The specification states that the enumeration software must > perform a depth-first search, so before proceeding to discover > additional functions/ devices on bus 0, it must proceed to search > bus 1. For PCI Express; for all I know, other technologies might enumerate differently or change the enumeration method with different driver versions. and Per driver. There's no guarantee that the kernel will load the drivers in the same order at boot. There was even a (specific) note in one of the RHEL 5 release notes about systems with NICs using both e1000 and e1000e being enumerated in a different order. >From >https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ : The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next.
Re: Naming of network devices - how to improve it in buster
On Thu, Jul 13, 2017 at 12:22 AM, Russell Stuart wrote: > > I still don't understand what use case the current scheme is aimed at. Stateless "/etc". Systems with multiple NICs where the order in which they're recognized by the kernel can vary.
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
On Wed, Jul 12, 2017 at 2:40 PM, Roger Lynn wrote:
> On 10/07/17 19:40, Marvin Renich wrote:
>>
>> There is an easy fix to revert the default behavior while still allowing
>> knowledgeable sysadmins to get the new behavior. On the other hand,
>> those who need to administer systems but are not sysadmins by trade (and
>> thus will have to do significantly more research to even know that the
>> older behavior is possible) are the ones who need the older behavior as
>> the default.
>
> This caught me out on a recent new installation, which gave me these new
> names which are too complicated to be usable. I wasted hours working out
> what had happened, how to fix it and how to write a udev rules file from
> scratch. And having just read this thread, I've discovered that the rules
> I've written are themselves apparently unreliable, for example:
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"
It's simpler to use (for example)
# cat /etc/systemd/network/77-en0.link
[Match]
MACAddress=1c:1b:0d:9a:34:98
[Link]
Name=en0
# cat /etc/systemd/network/77-en1.link
[Match]
MACAddress=1c:1b:0d:9a:34:9a
[Link]
Name=en1
This rule works even if you use sysvinit as pid 1.
Renaming NICs within the kernel's "eth*" namespace is discouraged upstream.
Suppose that the kernel names "1c:1b:0d:9a:34:9a" "eth0" and
"1c:1b:0d:9a:34:98" "eth1". You'll have a renaming clash when udev
tries to apply your rules.
Re: Too many Recommends (in particular on mail-transport-agent)
On Tue, Jun 6, 2017 at 9:55 AM, Adam Borowski wrote: > > dnsmasq-base: lxc > * BAD: how often are you on a network without a DNS server? The dnsmasq-base "recommends" is about providing a dhcp server for containers not a dns server. libvirt-daemon-system has the same "recommends" for its VMs.
Re: Too many Recommends (in particular on mail-transport-agent)
On Thu, Jun 1, 2017 at 1:00 PM, Henrique de Moraes Holschuh wrote: > > The initramfs-tools does not depend or recommend mdadm. However, > initramfs-tools is modular and its mdadm support is supplied by the > mdadm package. > > Dracut isn't modular, and its mdadm support is built-in. This is a key > difference. > > One needs to actually read dracut's source code to know how it would > behave in all boundary conditions related to mdadm support, in which > case it might only suggest or not even mention mdadm. It probably is > safe, but the point is that someone has to check it first. If mdadm isn't available, dracut'll print a warning along the lines of "mdadm will not be installed".
Re: policy for shipping sysctl.d snippets in packages?
On Sun, Apr 30, 2017 at 2:22 PM, Wouter Verhelst wrote: > On Sat, Apr 29, 2017 at 03:48:09PM -0400, Tom H wrote: >> On Thu, Apr 27, 2017 at 3:18 AM, Wouter Verhelst wrote: >>> >>> I didn't say RPM *doesn't* deal with changed files; I said ours >>> deals with it better. I stand by that. >> >> Sure; and an rpm or emerge user'll tell you that dpkg is inferior >> because an interactive upgrade's a crazy thing to do. > > Yes, sure. This discussion is getting increasingly side-tracked though. > > The original question was "should I install defaults in /etc or /usr?" > to which I replied that in Debian, we've traditionally done the former > rather than the latter, and that the latter feels like a result of an > ecosystem (other than ours) where dealing with conflicting changes to > configuration files is frowned upon. I think our way is better, but > I'm sure others disagree. If Debian decides to drop into "/etc" files that are dropped into "/usr/lib" (or "/lib") upstream because rpm and others can't handle config file upgrades, it would be a decision not based on facts.
Re: policy for shipping sysctl.d snippets in packages?
On Fri, Apr 28, 2017 at 12:08 PM, Wouter Verhelst wrote: > On Fri, Apr 28, 2017 at 04:21:17AM -0400, Tom H wrote: >> >> Did Linux development move as quickly as it does now? >> Did users experience more problems or failures when running those >> dist-upgrades? > > RedHat also did not support upgrades back when they did not wait four > years to do finish a new release. They do not support them, because > they *choose* not to support them, instead telling people to reinstall. > > Yes, that makes it easier for them to wait four years between releases. > But I think you have cause and effect swapped around. I've never even tried to dist-upgrade RHEL but I have dist-upgraded RHL and Fedora. It was/is perfectly do-able but they both had/have shorter release cycles. IF Red Hat had felt that there was a market for dist-upgrade support, it could have offered it for a extra fee, just like it offers an extended support subscription for companies that want to stick to want to stick to a release beyond the standard EOL or to a minor release. It does offer an *unsupported* upgrade via anaconda.
Re: policy for shipping sysctl.d snippets in packages?
On Thu, Apr 27, 2017 at 3:18 AM, Wouter Verhelst wrote: > On Wed, Apr 26, 2017 at 07:53:57AM -0400, Tom H wrote: >> On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst wrote: >>> >>> The "packages drop files in /usr/*, sysadmins override in /etc" way of >>> doing things is prevalent in the RPM world; in Debian, however, we >>> traditionally have packages drop files in /etc, and let the maintainer >>> change them in place. This is possible, because our package management >>> system deals better with changed files than does RPM (which must work >>> silently, rather than confirming things with the user). >> >> s/package management system deals better/package management system >> deals differently/ >> >> rpm doesn't have a problem with config file handling and deals with >> config files in a similar way that dpkg uses the "conffile" attribute >> to deal with them. rpm spec files use two (one-and-a-half?) macros: >> >> - "%config": "foo.conf" is replaced in an upgrade and saved as >> "foo.conf.rpmsave"; >> >> - "%config(noreplace)": "foo.conf" isn't replaced in an upgrade and >> the new "foo.conf" is installed as "foo.conf.rpmnew". > > Yes, I am aware of that (many of my customers use RedHat systems). > However, you will notice the complete absense of a "merge" option in the > above. This means that new configuration files are dropped on the > system, *without* any active notification to the user, so it's up to you > to figure out that this has happened and that you may have work to do. > > I didn't say RPM *doesn't* deal with changed files; I said ours deals > with it better. I stand by that. Sure; and an rpm or emerge user'll tell you that dpkg is inferior because an interactive upgrade's a crazy thing to do.
Bug#861482: ITP: fzf -- command-line fuzzy finder
Package: wnpp Severity: wishlist Owner: Tom Fitzhenry * Package name: fzf Version : 0.16.6 Upstream Author : Junegunn Choi * URL : https://github.com/junegunn/fzf * License : MIT Programming Lang: Golang Description : command-line fuzzy finder I use this as my shell's reverse-i-search. It brings up an ncurses interface in which to do fuzzy searching across my shell history. For example, suppose I know the following is in my history, but I cannot remember it: echo | openssl s_client -msg -connect nm.debian.org:443 -servername nm.debian.org 2>&1 | grep CertificateRequest With fzf, I press ^r, and am presented with an ncurses interface where I can then type something like "openssl nm CertReq" to quickly filter my entire history to just a few relevant entries, all while receiving visual feedback of the filtering process. It comes with plugins for bash, zsh, fish, vim. Since fzf is written in Go, I will apply for collaborative maintenance with the Go Team, and seek a mentor within that team to get this to Debian quality and uploaded. I have started packaging at https://github.com/tomfitzhenry/pkg-fzf and will move to the Go Team's Alioth repository if appropriate. Regards, Tom Fitzhenry
Re: policy for shipping sysctl.d snippets in packages?
On Thu, Apr 27, 2017 at 2:34 AM, Brian May wrote: > On 2017-04-27 16:19, Andrey Rahmatullin wrote: >> >> It seems you've missed the point (which was about 4 years between RHEL >> releases). > > There was almost three years between Woody (July 19th 2002) and Sarge (June > 6th 2005), yet we still allowed upgrades from Woody to Sarge. > > The time duration is irrelevant. It is the policy we have that we support > and test upgrades that matters. It is much easier to ignore upgrades and > recommend to reinstall from scratch, that means we don't need to test and > debug why upgrades break under various corner cases. Not so good for our > users however. Did Linux development move as quickly as it does now? Did users experience more problems or failures when running those dist-upgrades? Of course duration matters. It's not the same use-case as a Debian dist-upgrade but feel free to look up gentoo-user@ threads where a user kicks them off with "I haven't upgraded for 6 months, 1 year, 3 years." The longer the period, the more problems. Simply because Debian supports dist-upgrades doesn't make them easy or doesn't make the duration between them irrelevant. We're on a more or less two-year cycle and it makes dist-upgrades easier that if we were on a 4-year cycle; I don't see what can possibly be debatable about this.
Re: policy for shipping sysctl.d snippets in packages?
On Wed, Apr 26, 2017 at 8:12 PM, Luca Capello wrote: > On Wed, 26 Apr 2017 08:05:10 -0400, Tom H wrote: >> >> You can't dist-upgrade RHEL from 6 to 7 and you can't dist-upgrade >> Debian from 6 to 8 in one leap. > > Debian *does* support dist-upgrading between *following* releases only, > which is what we are talking about. > > And, in any case, for your example on Debian you will do 6 -> 7 -> 8. "in one leap"
Re: policy for shipping sysctl.d snippets in packages?
On Wed, Apr 26, 2017 at 2:55 PM, Ben Hutchings wrote: > On Wed, 2017-04-26 at 07:53 -0400, Tom H wrote: >>> On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst wrote: >>> The "packages drop files in /usr/*, sysadmins override in /etc" way of >>> doing things is prevalent in the RPM world; in Debian, however, we >>> traditionally have packages drop files in /etc, and let the maintainer >>> change them in place. This is possible, because our package management >>> system deals better with changed files than does RPM (which must work >>> silently, rather than confirming things with the user). >> >> s/package management system deals better/package management system >> deals differently/ >> >> rpm doesn't have a problem with config file handling and deals with >> config files in a similar way that dpkg uses the "conffile" attribute >> to deal with them. rpm spec files use two (one-and-a-half?) macros: >> >> - "%config": "foo.conf" is replaced in an upgrade and saved as >> "foo.conf.rpmsave"; >> >> - "%config(noreplace)": "foo.conf" isn't replaced in an upgrade and >> the new "foo.conf" is installed as "foo.conf.rpmnew". > > I didn't know about this, and I'm pleased to see that this is (now) > possible. Is this documented somewhere? (I've never been able to find > documentation of RPM macros that isn't very old and incomplete.) I first used it with RHEL 3 for some company-developed apps but it might predate that. But Google says that it was available since at least RHL 9: http://people.ds.cam.ac.uk/jw35/docs/rpm_config.html Fedora has an rpm draft doc: https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html >> So rpm isn't a factor; > > It is, because rpm is non-interactive and the above choice has to be > made by the packager and not the adminsitrator. It must've slipped my mind because I disable the interactivity. Indeed, dpkg has the advantage that an administrator can change the behavior at run-time, for the current transaction or for all, but that flexibility doesn't give dpkg an advantage over rpm for dropping config files in "/etc" rather than in "/usr/lib". >> upstreams drop files into "/usr/lib" because >> Red Hat is pushing the concept of all/almost-all distro-provided files >> in "/usr".
Re: policy for shipping sysctl.d snippets in packages?
On Mon, Apr 24, 2017 at 9:10 AM, Adam Borowski wrote: > > All of this is caused by Red Hat having no support for upgrades: > > https://access.redhat.com/solutions/21964 > > # Red Hat does not support in-place upgrades between major versions 4, 5 and > # 6 of Red Hat Enterprise Linux. (A major version is denoted by a whole > # number version change. For example, Red Hat Enterprise Linux 5 and Red > # Hat Enterprise Linux 6 are both major versions of Red Hat Enterprise > # Linux). > # > # In-place upgrades across major releases do not preserve all system > # settings, services or custom configurations. Consequently, Red Hat > # strongly recommends fresh installations when upgrading from one major > # version to another. > > # Red Hat currently supports only upgrades from Red Hat Enterprise Linux 6 > # to Red Hat Enterprise Linux 7 for specific/targeted use cases only. > > On the other hand, being able to effortlessly dist-upgrade is one of biggest > reasons many of us have chosen Debian. The reason that you can't dist-upgrade RHEL is that there's too large a gap between releases. Let's look at the release dates and compare like with like. RHEL 6: November 2010 RHEL 7: June 2014 Debian 6 (squeeze): February 2011 Debian 7 (wheezy): May 2013 Debian 8 (jessie): April 2015 You can't dist-upgrade RHEL from 6 to 7 and you can't dist-upgrade Debian from 6 to 8 in one leap.
Re: policy for shipping sysctl.d snippets in packages?
On Sun, Apr 23, 2017 at 3:00 PM, Wouter Verhelst wrote:
>
> The "packages drop files in /usr/*, sysadmins override in /etc" way of
> doing things is prevalent in the RPM world; in Debian, however, we
> traditionally have packages drop files in /etc, and let the maintainer
> change them in place. This is possible, because our package management
> system deals better with changed files than does RPM (which must work
> silently, rather than confirming things with the user).
s/package management system deals better/package management system
deals differently/
rpm doesn't have a problem with config file handling and deals with
config files in a similar way that dpkg uses the "conffile" attribute
to deal with them. rpm spec files use two (one-and-a-half?) macros:
- "%config": "foo.conf" is replaced in an upgrade and saved as
"foo.conf.rpmsave";
- "%config(noreplace)": "foo.conf" isn't replaced in an upgrade and
the new "foo.conf" is installed as "foo.conf.rpmnew".
So rpm isn't a factor; upstreams drop files into "/usr/lib" because
Red Hat is pushing the concept of all/almost-all distro-provided files
in "/usr".
[OT: If I've *had* a complaint about
"/usr/lib/{modules-load.d,sysctl.d,tmpfiles.d}", it's that, when I
first looked for them on Debian, I expected them to be under "/lib"
and not "/usr/lib" given that systemd installs its boot-time files
under "/lib/systemd".]
Re: Can we kill net-tools, please?
On Sun, Jan 8, 2017 at 10:55 AM, Andrey Rahmatullin wrote: > On Sun, Jan 08, 2017 at 10:49:23AM -0500, Tom H wrote: >> >> You can use >> >> ip a sh lo (if you have bash-completion installed, "a" will >> complete to "addr" and "sh" will complete to "show") >> >> instead of "ip a show dev lo" above (still longer than "ifc >> though). > > OTOH "ip a" is not longer than that. Sure. But I was replying to displaying "ip a" for a specific NIC.
Re: Can we kill net-tools, please?
On Fri, Jan 6, 2017 at 7:58 PM, Toni Mueller wrote: > On Thu, Dec 29, 2016 at 09:01:51PM +0500, Andrey Rahmatullin wrote: >> On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote: >>> Ifconfig has been deprecated; you should probably use "ip a show >>> dev lo" instad of the shorter and more convenient "ifconfig lo" >> >> ... and often wrong > > The BSD ifconfig can do this with ease, and since ages, too. Why is > the Linux ifconfig _so_ different? Forking for the sake of it? Is there any relationship between current ifconfig on Linux and the BSDs, other than the name? I don't think so. The BSDs have continued to develop ifconfig, adding many features and options. > Eg adding an IPv6 address: > # ifconfig em0 inet6 address alias > > and removing it: > # ifconfig em0 inet6 address -alias On Linux, you can do the same with ipv6 ifconfig eth0 inet6 add ipv6_address but for ipv4 you have to label the NIC as an alias ifconfig eth0:0 ipv4_address You can use ip a sh lo (if you have bash-completion installed, "a" will complete to "addr" and "sh" will complete to "show") instead of "ip a show dev lo" above (still longer than "ifc though).
Re: Can we kill net-tools, please?
On Fri, Dec 30, 2016 at 2:32 AM, Andrey Rahmatullin wrote: > > Do you really think that > > wlp3s0: flags=4163 mtu 1500 > inet 192.168.** netmask 255.255.255.0 broadcast 192.168.** > inet6 fe80::** prefixlen 64 scopeid 0x20 > ether e4:**:ca txqueuelen 1000 (Ethernet) > RX packets 66323088 bytes 90518262611 (84.3 GiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 18425793 bytes 2920636610 (2.7 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > is clearer than > > 3: wlp3s0: mtu 1500 qdisc mq state UP group > default qlen 1000 > link/ether e4:***:ca brd ff:ff:ff:ff:ff:ff > inet 192.168**/24 brd 192.168.** scope global dynamic wlp3s0 >valid_lft 70216sec preferred_lft 70216sec > inet6 fe80:**/64 scope link >valid_lft forever preferred_lft forever > > ? > > To me they are the same. Note that ifconfig too has cryptic uppercase > jumble and cryptic lowercase jumble and doesn't have any separators > between field names and values. Those used to ifconfig's old output might dislike its new output too: JESSIE # ifconfig en0 en0 Link encap:Ethernet HWaddr 08:00:27:31:6a:8c inet addr:192.168.43.242 Bcast:192.168.43.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 # ip a sh en0 2: en0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:31:6a:8c brd ff:ff:ff:ff:ff:ff inet 192.168.43.242/24 brd 192.168.43.255 scope global en0 valid_lft forever preferred_lft forever STRETCH # ifconfig en0 en0: flags=4163 mtu 1500 inet 192.168.43.242 netmask 255.255.255.0 broadcast 192.168.43.255 ether 08:00:27:31:6a:8c txqueuelen 1000 (Ethernet) # ip a sh en0 2: en0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:31:6a:8c brd ff:ff:ff:ff:ff:ff inet 192.168.43.242/24 brd 192.168.43.255 scope global en0 valid_lft forever preferred_lft forever The stretch output's similar to the output on the BSDs and Solaris...
Verlaag uw drinkwaterfactuur
Verlaag uw drinkwaterfactuur Kies voor een SipWell waterkoeler En bied uw klanten en werknemers water van bronkwaliteit Ontdek alle voordelen Waarom kiezen voor SipWell waterkoelers? -Unieke designs voor elk interieur -Geen zorgen om levering en facturatie -Gezondere en productievere werknemers -Uw klanten worden verwend -Extra opties als bruis of heet water Meer info over SipWell in uw bedrijf Ontdek waarom bedrijven voor SipWell kiezen... This email was sent to debian-devel@lists.debian.org. If you are no longer interested you can unsubscribe instantly: http://mailexpert.hannibal.be/t/r-u-sjyhhul-hryhpidjt-n/
Bug#814306: ITP: spin -- a software verification tool
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org I'm working on Debian packages for Gerard J. Holzmann's Spin software verification tool, which has recently become available under the BSD 3-Clause license. Holzmann's original paper "The Model Checker: SPIN" has been cited over a thousand times in academia according to ACM. Spin has also seen success in a number of commercial and government projects, including NASA's investigation of alleged unintended acceleration in the Toyota Camry MY05's control software. Packaging WIP is available here: https://github.com/thomaslee/spin-debian Initial indications are the packaging will be relatively simple with some minimal patches. Further reading: http://spinroot.com https://en.wikipedia.org/wiki/SPIN_model_checker https://en.wikipedia.org/wiki/Promela http://spinroot.com/spin/success.html -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
Re: support for merged /usr in Debian
On Sun, Jan 10, 2016 at 12:09 PM, Marc Haber wrote: > On Sun, 10 Jan 2016 09:53:52 +0100, Tom H wrote: >> >> Lennart didn't even say that he wanted to get rid of "EnvironmentFile=". >> >>> From the same-named thread on systemd-devel@: >> >> --- 8< --- >> 1) >> I probably should never have added EnvironmentFile= in the first place. >> >> 2) >> I think EnvironmentFile= was a mistake, and I explained why. But then >> again, I am not planning to remove it, and I never suggested that. >> --- > 8 --- >> >> He advocated the use of drop-ins, as you (Philipp) do. > > Yes. But two of his militant fanbois suggested in the following that > the option should be removed because of Lennarts reasoning. In the > following, one of them said that if the option will be removed in the > future, it would be "our" because "we" had been using the option > "wrong" and have thus "forced lennart" to remove it since we refused > to be "educated" about "proper" use of systemd. Johann (I can't think of the other "fanboi" to whom you're referring) has argued in the past for the removal of rc.local and sysvinit compatibility. Let's assume that Lennart removes support for them as well as for "EnvironmentFile=", will it really be something that'll be worth getting upset about? I'm not trying to provoke you, I'm just thinking it through. For EnvironmentFile, does it really matter whether you edit a file under "/etc/default/" or under "/etc/systemd/system/"? As I said up-thread, I'm wouldn't like setting up nfs without "EnvironmentFile=" but it's something that'll just take a little longer initially, whether I'm using config management or not. And then it'll be the same, since I only change these files at setup. For rc.local, does it really matter whether you edit "/etc/rc.local" or a file under "/etc/systemd/system/"? Personally, even if I've used rc.local when in a hurry, I've always made a point of creating a sysvinit script, upstart job, or systemd service unit later. If the rc.local support's removed, I might even create my own "/etc/systemd/system/rc-local.service" to parse "/etc/rc.local" for cases when I don't have the time to think through the dependencies of a proper unit. There's residual anger at systemd because it more or less snookered distros and users into adopting it, but being angry at every little change seems OTT, no matter how Lennart expresses his musts and must-nots and his likes and dislikes.
Re: support for merged /usr in Debian
Sorry. Not meant for list. :( On Sun, Jan 10, 2016 at 9:59 AM, Tom H wrote: > Off-list. > > On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt wrote: >> >> What is the advantage of having a optional-merged-/usr? > > Imagine the opposition if this had been proposed as a non-optional change! > > (BTW, I'll take this opportunity to thank you for two of your recent > proposals, the re-work of the list of packages to be installed by > default and the re-naming of the security suite. Thanks!)
Re: support for merged /usr in Debian
Off-list. On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt wrote: > > What is the advantage of having a optional-merged-/usr? Imagine the opposition if this had been proposed as a non-optional change! (BTW, I'll take this opportunity to thank you for two of your recent proposals, the re-work of the list of packages to be installed by default and the re-naming of the security suite. Thanks!)
Re: support for merged /usr in Debian
On Wed, Jan 6, 2016 at 12:03 AM, Philipp Kern wrote: > On 2016-01-04 11:30, Marc Haber wrote: >> >> Please also notice that this is the only option for ExecStart in >> systemd units. Well played, Lennart. > > Similarly skeleton-based init scripts use the full path as well. It helps if > you can stat() it. Which, I guess, you could by extension by using "which" > and the like. On the other hand init scripts are supposed to be runable in > "env -i". Now, what would the PATH be for systemd to use? My skeleton-based > init scripts ship their own PATH (yay, duplication and decentral > configuration). I can see how you would want to use EnvironmentFile for > that. But then, why not simply override ExecStart? And even then I don't see > the point. (One reply would be "to reuse the distro-provided commandline > arguments", which is fair, but you are already redirecting the path to the > binary from the default anyway and are not using the distro one.) > > You can continue to childishly blame Lennart for everything, but that might > cause others to stop taking you seriously. Which isn't really what you > deserve. Lennart didn't even say that he wanted to get rid of "EnvironmentFile=". >From the same-named thread on systemd-devel@: --- 8< --- 1) I probably should never have added EnvironmentFile= in the first place. 2) I think EnvironmentFile= was a mistake, and I explained why. But then again, I am not planning to remove it, and I never suggested that. --- >8 --- He advocated the use of drop-ins, as you (Philipp) do. There's one daemon (that I use) where this is a PitA; nfsd and its associated executables. It would mean having to edit multiple units rather than two files on Debian/Ubuntu and one file on Gentoo/RHEL.
Re: support for merged /usr in Debian
On Sun, Jan 3, 2016 at 6:17 PM, Iustin Pop wrote:
> On 2016-01-03 12:59:01, Tom H wrote:
>>
>> I don't like usr-merge because it goes against my historical
>> expectation that "/{,s}bin" be separate from their /usr namesakes and
>> contain binaries required for boot.
>
> OK, so adjust your historical expectation. It's not a technical issue,
> it's simply a matter of expectations, which have no reason to stay the
> same for ever.
Did you read the next para of my email?!
Re: support for merged /usr in Debian
On Sun, Jan 3, 2016 at 11:04 AM, Daniel Reurich wrote: > On 03/01/16 22:33, Philip Hands wrote: >> Daniel Reurich writes: >>> Because systemd doesn't work without /usr on the root partition isn't a >>> good reason either. >> >> You are right ... it is a poor reason, because it is pure fantasy. > > Then why is it that since the introduction of systemd is having /usr on > a separate partition suddenly considered evil and systemd complains > loudly about it. It always has worked and does work fine for me with > sysvinit It's udev (already pre-systemd) that needs "/usr" early, with sysvinit or any other init. Whether this need breaks split-usr can be a matter of opinion because there'll always be some people saying "it's OK for me." But does this mean that it's OK for all? It also doesn't mean that udev doesn't have to go through some workarounds in order to make it work. >>> That just means systemd is broken by design and needs to be fixed. >> >> If what you claimed were true, then I'd agree with you, but since all >> the systems I've upgraded to systemd have a separate /usr, and are >> working without any issue whatsoever, this drivel can be safely ignored. > > Then what's the problem and why are we even having this conversation > about merged /usr??? usr-merge isn't correcting the broken-ness of split-usr. Mounting a separate "/usr" via the initramfs is the fix to that problem.
Re: support for merged /usr in Debian
On Sat, Jan 2, 2016 at 6:42 PM, Geert Stappers wrote:
> On Fri, Jan 01, 2016 at 03:53:03PM +0100, Marco d'Itri wrote:
>> On Jan 01, Ian Jackson wrote:
>> With a merged /usr you would be able to serve the whole OS over NFS (and
>> even share it among multiple systems without the constant threat of
>> having / and /usr diverge) and only configuration + data from the local
>> disk, which makes this kind of setup much more useful.
>
> "whole OS over NFS" is the same as "whole OS on /usr"
>
> A design with "whole OS over NFS" breaks the good pratice of having
> A design with "whole OS on /usr" breaks the good pratice of having
> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable.
I don't like usr-merge because it goes against my historical
expectation that "/{,s}bin" be separate from their /usr namesakes and
contain binaries required for boot.
On RHEL and RHEL clone systems that I manage, I reconcile this
expectation with RHEL's usr-merge by thinking of the initramfs as the
new "/" (it's easier in RHEL than in Debian because the initramfs has
"real" binaries rather than their busybox equivalents).
> To me is this "TheUsrMerge" something like among
> * "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
> * "there was a question about /bin/kill and /usr/bin/killall being
> inconsequent"
Your mentioning of "kill" reminds me of a samba-devel@ thread where
three RH samba developers insisted that the upstream-supplied systemd
units should use "/usr/bin/kill" in spite of the fact that a fellow
samba developer pointed out that the "/bin" symlink obviated the need
for "/usr" in "ExecStart" and that this change voided the systemd
intent to have distros use upstream units as-is.
So, even though Marco's proposing a non-compulsory usr-merge, I expect
that it'll become at some point the unique and default Debian setup,
if only to reduce the delta with the various RH-dominated upstreams.
> * "we could not agree if p{erl,ython,hp} should in /bin or in /usr/bin"
> * "when calling `foo` we rely on $PATH. To avoid $PATH we call `/bin/foo`,
> to have a reason to rant it should be /usr/bin/foo"
> * "reverting a historic decission is much better then accepting a historic
> decission"
> * "just because we can"
> * "others doing also"
>
> In other words: I don't yet see a _good_ reason for "TheUsrMerge".
>
> And I think that it is ill-named,
> it should be named "PutAllExecutablesInRootFS" :-)
>
> And the "PutAllExecutablesInRootFS" is
> in fact "put all executables in a single file system".
"put all executables in a single file system" is the main/only benefit
of usr-merge.
To Simon Richter:
You mentioned earlier in the thread that you had resource-constrained
systems possibly incompatible with an initramfs.
Gentoo mandated at least two years ago that systems with a separate
"/usr" have an initramfs. A (I suspect unhappy) developer created a
busybox-based binary called "ginit" to mount "/usr" early without an
initramfs. IIRC, you have to set "init=/ginit" at the kernel cmdline
to use it - and it hands over boot to "/sbin/init" once it's done its
job.
Should you be interested, the source must be
"sys-apps/busybox/files/ginit.c" in the Gentoo distfiles tree.
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
On Wed, Nov 11, 2015 at 4:23 PM, Bjørn Mork wrote: > Bjørn Mork writes: >> >> "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do >> anything unless you run the systemd-sysctl service. > > Sorry, should have researched this better first. sysctl WILL use > "/usr/lib/sysctl.d/" if it exists. procps won't create it, but it is > supported. No prob. I didn't look closely enough at codesearch.debian.net but I suspect that the "/usr/lib/sysctl.d/" hits are for binaries than scan it rather than packages that drop a file into it. I remember dracut, libvirt, and procps.
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
On Wed, Nov 11, 2015 at 4:16 PM, Bjørn Mork wrote: > Tom H writes: >> >> systemd isn't the first package to allow/promote shipping distro >> settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev >> and polkit/policykit have behaved like this for a long time. There's >> also "/usr/lib/sysctl.d/" where a distro ship settings that can be >> overridden via "/etc/sysctl.d/". > > "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do > anything unless you run the systemd-sysctl service. > > "/etc/sysctl.d/" used to be owned by procps, and will still be used by > /etc/init.d/procps whether or not you run systemd-sysctl. Perhaps a few years ago: # strings $(which sysctl) | grep 'sysctl.d' /run/sysctl.d /etc/sysctl.d /usr/local/lib/sysctl.d /usr/lib/sysctl.d # dpkg -S $(which sysctl) procps: /sbin/sysctl # Also codesearch.debian.net shows more than systemd as a user of "/usr/lib/sysctl.d/".
Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
On Wed, Nov 11, 2015 at 10:37 AM, Marc Haber wrote: > > I violently disagree. We have always done it the other way, and had > the advantage that our conffile handling (which used to be and IMO > still is far superior to everything else other distributions have) > could notice if _both_ local changes and distribution changes happened > and ask the use what to do in this case. > > Adopting the systemd way here deprives our users of this advantage, > reducing Debian's operation safety. > > Just imagine Tom Smith having copied /lib/systemd/foo.service to > /etc/systemd/foo.service, and changed the /etc copy to better fit his > needs. Debian later finds that a bug in /lib/systemd/foo introduces a > security hole and ships a new version of that file. Tom installs the > security update, feels safe but isn't since noone warned him that the > security fix is not even looked at by his systems since his local copy > of the (old, insecure) file in /etc overrides the fix. > > Jane Jones, being smarter than her colleague Tom, uses the > /etc/systemd/foo.service.d approach to add her local changes. If we > ship a security update to /lib/systemd/foo.service, it depends on our > change whether Jane gets either the fix, or her local addition > overrides the fix as it was the case with Tom, or she gets > "interesting" local breakage due to a security update if our change > does not fit her change since she now inadvertently gets a mixture of > her and our changes. > > In my humble opinion, it is really bad if a package _this_ central and > important to Debian deviates from the Debian way this severely. It is, > IMO, a very good example about how badly systemd integrates in the > Debian ecosystem and that it was a bad decision to blindly follow how > systemd upstream handles configuration. The packaging should instead > follow how _Debian_ handles configuration. This is Debian in the first > place. If systemd-delta could be enhanced to apply to one unit (its current output can only be limited to a specific unit type), it could be integrated into the installation of packages providing systemd units. systemd isn't the first package to allow/promote shipping distro settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev and polkit/policykit have behaved like this for a long time. There's also "/usr/lib/sysctl.d/" where a distro ship settings that can be overridden via "/etc/sysctl.d/". I don't know how extensively it's used on Debian - it's empty on my systems - but systemd used to modify, at least, kernel.sysrq in older systemd versions in this way.
Re: Q: why binary-log by systemd-journald is not enabled by default?
On Tue, May 12, 2015 at 7:10 AM, Piotr Ożarowski wrote: > [Hideki Yamane, 2015-05-10] >> On Sun, 10 May 2015 00:56:43 -0300 >> Henrique de Moraes Holschuh wrote: >>> >>> And I wish it would keep /var/log/dmesg (and its rotation). That thing is >>> really useful for user support when dealing with kernel and boot issues. >> >> Is it enough to ask users to exec "sudo journalctl"? > > IMO a better idea is to add them to systemd-journal group Shouldn't "systemd-*" groups be reserved for systemd system accounts? th@localhost:~$ grep systemd /etc/passwd systemd-timesync:x:100:104:systemd Time Synchronization,,,:/run/systemd:/bin/false systemd-network:x:101:105:systemd Network Management,,,:/run/systemd/netif:/bin/false systemd-resolve:x:102:106:systemd Resolver,,,:/run/systemd/resolve:/bin/false systemd-bus-proxy:x:103:107:systemd Bus Proxy,,,:/run/systemd:/bin/false th@localhost:~$ grep systemd /etc/group systemd-journal:x:102: systemd-journal-remote:x:103: systemd-timesync:x:104: systemd-network:x:105: systemd-resolve:x:106: systemd-bus-proxy:x:107: I can run "journalctl" as non-root because I'm a member of "adm". th@localhost:~$ id uid=1000(th) gid=1000(th) groups=1000(th),4(adm),27(sudo),46(plugdev),115(lpadmin) th@localhost:~$ journalctl -- Logs begin at Tue 2015-05-12 08:19:51 EDT, end at Tue 2015-05-12 08:34:59 EDT. -- May 12 08:19:51 localhost.localdomain systemd-journal[232]: Runtime journal is using 8.0M (max allowed 78.9M, trying to leave 118.4M free of 781.2M available → current limit 78.9M). May 12 08:19:51 localhost.localdomain systemd-journal[232]: Runtime journal is using 8.0M (max allowed 78.9M, trying to leave 118.4M free of 781.2M available → current limit 78.9M). May 12 08:19:51 localhost.localdomain kernel: Initializing cgroup subsys cpuset May 12 08:19:51 localhost.localdomain kernel: Initializing cgroup subsys cpu May 12 08:19:51 localhost.localdomain kernel: Initializing cgroup subsys cpuacct It's set up by "systemd-tmpfiles-setup.service". th@localhost:~$ grep '/run/log/journal' /usr/lib/tmpfiles.d/* /usr/lib/tmpfiles.d/systemd.conf:z /run/log/journal 2755 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:Z /run/log/journal/%m ~2750 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:a+ /run/log/journal/%m - - - - d:group:adm:r-x /usr/lib/tmpfiles.d/systemd.conf:A+ /run/log/journal/%m - - - - group:adm:r-x th@localhost:~$ grep '/var/log/journal' /usr/lib/tmpfiles.d/* /usr/lib/tmpfiles.d/systemd.conf:z /var/log/journal 2755 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:z /var/log/journal/%m 2755 root systemd-journal - - /usr/lib/tmpfiles.d/systemd.conf:a+ /var/log/journal/%m - - - - d:group:adm:r-x /usr/lib/tmpfiles.d/systemd.conf:A+ /var/log/journal/%m - - - - group:adm:r-x -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=sye7ppyqc_gcu2afaft_-anvkp6vuq-vxh2tgaaoaz...@mail.gmail.com
Bug#764252: ITP: librocket -- User interface middleware package based HTML and CSS
Package: wnpp Severity: wishlist Owner: Tom Mason * Package name: librocket Version : 1.3 Upstream Author : CodePoint Ltd, Shift Technology Ltd, and contributors * URL : http://librocket.com * License : MIT Programming Lang: C++ Description : User interface middleware package based HTML and CSS Ui library for games, used in warsow amongst other things. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006170449.2601.47270.reportbug@PONG
Bug#754504: ITP: libpedantic-clojure -- A Clojure library designed to be used with pomegrante to check for common unexpected cases.
Package: wnpp Severity: wishlist Owner: Tom Marble * Package name: libpedantic-clojure Version : 0.1.0 Upstream Author : Nelson Morris * URL : https://github.com/xeqi/pedantic * License : EPL-1.0 Programming Lang: Clojure Description : A Clojure library designed to be used with pomegrante to check for common unexpected cases. This package is a build-dep for leiningen 2 -- an essential build tool for Clojure packages. This package will be created and maintained by the Debian Clojure Maintainers . Paul Tagliamonte has offered to sponsor this package. Regards, --Tom -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711195024.9835.71454.report...@ficelle.info9.net
default init on non-Linux platforms
On Thu, 20 Feb 2014 22:28:56 +0800, Thomas Goirand wrote: > On 02/20/2014 09:02 PM, Tom H wrote: Thanks for your answer and apologies for the delay in responding but my $dayjob's been keeping me very busy. >> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv >> doesn't have? You're being unfair to sysvinit+sysv-rc+insserv, although I have to admit that openrc is better and more cleanly designed from a user perspective because the combination of rc-update, rc-service, and rc-status is better than using service except to enable/disable a service where you have to use update-rc.d - and, if you want an output that's more human-friendly than "insserv -s", you have to install and use chkconfig. > Just to name a few: > - getting rid of the ugly LSB headers Beauty is in the eye of the beholder. The "Short-Description" and "Description" LSB fields are useless, but I don't find Debian's LSB headers and Gentoo's squiggle-delimited stanzas any more beautiful or uglier than the other. What's important is that they do the job of allowing their respective rc routines order the startup - and they both do so. As a sysadmin who works with different distributions, I find it quite frustrating that sysv-rc uses "Required-Start" and Should-Start", openrc "need" and "use", and systemd "Requires" and "Wants" to mean the same thing. Although it's not difficult to keep track of what's what, why should we have to? > - cgroup supports to kill processes IIRC, Patrick Lauer claimed to have written openrc's cgroup support in one afternoon. And IIUC that support'll have to rewritten once the kernel's cgroup maintainer makes the changes that he's announced and non-systemd sysinits have to use Ubuntu's in-development cgroup manager (since systemd's cgroup manager's integrated into its pid 1). > - rc_hotplug (a hotplugged service is one started by a dynamic dev > manager when a matching hardware device is found). AIUI openrc simply leverages udev to hotplug devices; but I'm only an occasional Gentoo user so I might have misundertood the process. > - Checks if a daemon is really started by start-stop-daemon > - Dependency loop breaking system What does this mean? That there are bugs in the dependency headers in the 1000-odd initscripts in Debian where openrc can work through the problem and insserv send you to the BTS? > - Named runlevels (I already talked about that) I don't see this as a must-have feature. The default runlevels of sysinit, boot, default, single, reboot, shutdown where "sysinit" groups the services that are started in single-user mode and "boot" groups the services that are started by "default" and any user-defined runlevel but aren't started in single-user mode. However, the only one that you can switch to by name is "default" (with "rc default"). For the others, you have to use "init " just like sysv-rc. In Gentoo, it makes sense to use named runlevels because if you install rsyslog, for example, you have to run "rc-update add rsyslog default" to ensure that rsyslog is started at boot. I guess that it makes more sense that running "rc-update add rsyslog 3" but in Debian, the maintainer scripts take care of this. If a Debian user wants to create a custom runlevel, calling it "4" or "thomasg" isn't that big a deal. There's also a weird relationship between named levels, possibly because "default" is special-cased. I don't have a Gentoo box at hand to retest this but I did do this in the past. When you boot to the "default" runlevel, "who -r" return "3". If you run "init 5", the runlevel switches to "5" instantaneously, and "rc-status --all" lists all the same services as "started". If you boot to the "default" runlevel, rename "/etc/runlevels/default" to "/etc/runlevels/thomasg", and run "init 5", the runlevel switches to "5" by shutting down the daemons in "thomasg", and "rc-status --all" lists the sysinit and boot services as "started" and the thomasg services as "stopped". Perhaps you'd have to run "rc thomasg" before "init 5" for the "thomasg" daemons not to be stopped but it's non-intuitive. I know that it's a contrived, artificial (mis)manipulation that's unlikely in a real-world situation but there does seem to be a disconnect somewhere. > - Stateful system (see rc-status) see insserv > - Dependency caching system (so you wont have to wait for its &
default init on non-Linux platforms
On Thu, 20 Feb 2014 14:19:30 +0900, hero...@gentoo.org wrote: > Tollef Fog Heen writes: >> >> It's probably better to just contribute your changes to the sysv-rc >> version and so make that one able to manage openrc in addition to the >> others it already knows how to. No point in forking it. > > Forking was a decision made by me in the early phase of packaging > OpenRC. At that time I referred to the way file-rc handled update-rc.d > as in > > sysvinit: /usr/share/sysvinit/update-rc.d > > A central package providing update-rc.d and invoke-rc.d is nice. > Though it should not be sysv-rc, which OpenRC is intending to replace. What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv doesn't have? https://wiki.debian.org/Debate/initsystem/openrc doesn't make that case and none of the members of the CTTE explained their "openrc > sysvinit" votes (unless I missed that point in the 100s/1000s of #727708 posts). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5305fcf8.90...@gmail.com
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 21:50:53 -0400, Theodore Ts'o wrote: > > It's not necessarily the init script author who might want the degrees > of freedom, but the local system administrator. > > The most basic is the idea that whether you can control (via shell > scrpit fragments) whether or not a service should start at all, and > what options or environments should be enabled by pasing some file. > The fact that we can put that sort of thing in configuration files > such as /etc/default/*, for example. > > Yes, yes, you can do this via if you use system V init scripts scripts > in backwards compatibility mode, but you've argued that we should be > moving briskly away from that. In which case system administrators > will need to hand-edit the services files by hand, which will no doubt > increase the chances of conflicts at package upgrade time, compared to > if the configuration options were isolated away in files such as > /etc/default/rsync (for example). Both upstart and systemd allow you to source any file and run any script from their .conf/.service files. In Fedora 19: You can source anything with "EnvironmentFile=" and run anything from "ExecStartPre=", "ExecStart=", "ExecStartPost=". "/usr/lib/systemd/system/iptables.service" has "ExecStart=/usr/libexec/iptables/iptables.init start" where "/usr/libexec/iptables/iptables.init" is the "/etc/rc.d/init.d/iptables" sysvinit script of Fedora 15. iptables also has "/usr/libexec/initscripts/legacy-actions/iptables/save" and it runs "exec /usr/libexec/iptables/iptables.init save". Also, "/usr/lib/systemd/system/nfs-server.service" sources "/etc/sysconfig/nfs" with "EnvironmentFile=/etc/sysconfig/nfs" and runs scripts in "/usr/lib/nfs-utils/scripts/". (It's surprising that there isn't a canonical location for custom systemd scripts. I don't have an Arch instance on which to check, but AFAIK its iptables.service calls a script that's in "/usr/lib/systemd/scripts/".) In Ubuntu 13.10: I would've liked to compare like for like but neither iptables-persistent and nfs-kernel-server have upstart jobs. Let's assume that "/etc/init/nfs-kernel-server.conf" exists and that you want to override it. # vi /etc/init/nfs-kernel-server.override ... script [ -r /home/ted/ted-nfs-kernel-server ] \ && . /home/ted/ted-nfs-kernel-server end script -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5272144a.3000...@gmail.com
Re: Proposal: switch default desktop to xfce
As a matter of personal preference I would like to see something other than gnome as default. I've had much better luck converting users from windows, specifically older and middle aged users, with xfce or lxde. But this conversation really goes back to the init conversation. On which I suggest we go for freedom of choice and upholding principles of the Unix philosophy. On Oct 25, 2013 12:33 PM, "Guillem Jover" wrote: > On Fri, 2013-10-25 at 11:07:09 +, Thorsten Glaser wrote: > > • On a VM, I might want to run very low-consuming software only, to lower > > the cost of separating things into VMs of their own. (I’ll be writing a > > syslog dæmon some day because sysklogd (three processes, c’mon!) is now > > removed from the archive and both rsyslog and syslog-ng are way > > too heavy-weight for this, for example.) > > Before reimplementing something from scratch you might want to > consider inetutils-syslogd (which I'm pretty happy with :), or > perhaps dsyslog (although I've never tried it). > > Thanks, > Guillem > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20131025173321.gb15...@gaara.hadrons.org > >
Fwd: ITP: capnproto -- Cap'n Proto: a fast data interchange format & capability-based RPC system.
Gmail thwarted my attempts to add the X-Debbugs-CC header, so I'm forwarding this ITP on manually. Relevant bug number is 719782 Cheers, Tom -- Forwarded message -- From: Tom Lee Date: Thu, Aug 15, 2013 at 3:02 AM Subject: ITP: capnproto -- Cap'n Proto: a fast data interchange format & capability-based RPC system. To: sub...@bugs.debian.org Package: wnpp Severity: wishlist Owner: Tom Lee * Package name: capnproto Version : 0.2.0 Upstream Author : Kenton Varda * URL : http://kentonv.github.io/capnproto/index.html * License : BSD Programming Lang: C++ Description : Cap'n Proto: a fast data interchange format & capability-based RPC system. Similar to Protocol Buffers, Cap'n Proto is an efficient means of serializing structured data to be transferred across a network or written to disk. Users write a Cap'n Proto definition file that drives a code generator, which in turn emits C++ code for encoding & decoding messages in the Cap'n Proto format. In addition to being extremely fast, Cap'n Proto also smooths over some of the rougher aspects of Protocol Buffers & introduces a number of new features to boot. Cap'n Proto is actively maintained by the primary author of Protocol Buffers v2, Kenton Varda. -- Tom Lee / http://tomlee.co / @tglee -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKwFPQ_V68tT=u+bpz7ynktx2-4ndagog565rtxsfy6ymu-...@mail.gmail.com
Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Mon, 5 Aug 2013 13:08:28 -0400, Thomas Hood wrote: (I had an exchange of emails with Thomas off-list and he suggested that I reply on-list.) > With the nsswitch configuration > > hosts: files ... dns ... myhostname > > myhostname resolves the system hostname if nothing else does so > first. So it can be overridden either by DNS or by /etc/hosts. If > the system hostname changes, no file has to be edited. Nice. > > Also nice is the fact that myhostname resolves the system hostname > to an external address if there is one, increasing the chances that > the result is similar to what would be obtained from DNS. The output below is from Debian Sid with libnss-myhostname installed and Fedora 19. On Debian, getent outputs the system's IP address for 127.0.1.1, whereas on Fedora, getent outputs 127.0.0.2 for 127.0.0.2. Debian Sid [root@debdeb:/etc]# cat hostname debdeb [root@debdeb:/etc]# cat hosts 127.0.0.1 localhost [root@debdeb:/etc]# getent hosts 127.0.1.1 192.168.1.250 debdeb Fedora 19 [root@fedfed:/etc]# cat hostname fedfed.defdef [root@fedfed:/etc]# cat hosts 127.0.0.1 localhost [root@fedfed:/etc]# getent hosts 127.0.0.2 127.0.0.2 fedfed.defdef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5204124c.7030...@gmail.com
Re: Dual licensing for KDE-Oxygen Icons
Hi Sune, Thanks this is how I also always interpreted it as well, one can simply choose. Oxygen was dual licensed from the beginning but the 2 option was removed with http://websvn.kde.org/trunk/kdesupport/oxygen-icons/COPYING?r1=699615&r2=760422 5 years ago. Tom Am 14.02.13 10:15, schrieb Sune Vuorela: > On 2013-02-14, Tom Schindl wrote: >> They dual licensed their icons in history but removed this option >> there've been multiple factors to do this and I was told that Debian >> was one of the reasons because you had problems with this dual licensing >> option. > > If anyone said Debian has problems with dual licensing, someone must > have misunderstood something or someone. > > Dual licensing usually means 'you can choose any of the two' for > complying. > > e.g. dual licensed (GPL|proprietary) is seen quite a lot. Debian just > chooses the GPL license. > > iirc back in the days, the oxygen icons was specifically *only* under > cc-by-(sa)-2.0 and given that one isn't considered free by Debian, we > got them to add lgpl as an alternative. > > /Sune > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH tom schindl geschäftsführer/CEO eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone++43 512 935834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511caeea.5060...@bestsolution.at
Dual licensing for KDE-Oxygen Icons
Hi, I'm currently trying to get the KDE-Artist Team to once more dual license their Icon-Set under LGPL and Creative Common Attribution-ShareAlike 3.0 License. They dual licensed their icons in history but removed this option there've been multiple factors to do this and I was told that Debian was one of the reasons because you had problems with this dual licensing option. Can anyone here shed some light on this? Why can it be a problem to Debian if something is available under LGPL and another license (which itself even allows commerical usage)? Before I start with the monster work of going through the history of icons to find out who provided them I need to know if a dual licensing is possible at all. Does anyone here know of other parts of Debian who use a dual licensing option, e.g. Apache 2.0 + LGPL, ...? If you want to know more about the background of why I'm trying to do this. You can take a look at my blog http://tomsondev.bestsolution.at/2013/02/13/fed-up-with-famfamfam-icons-for-eclipse-org-lets-get-oxygen-icons/ Thanks for your help Tom -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH -------- tom schindl geschäftsführer/CEO eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone++43 512 935834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511ca7e8.3040...@bestsolution.at
Re: Providing official virtualisation images of Debian
Hello Charles, Some unofficial Debian AMIs are already being produced, see http://wiki.debian.org/Cloud/AmazonEC2Image I have updated that list with the most recently created images in all regions. Thanks for reminding me of it To enable secure SSH login, booting after kernel update, and other tasks, some init, grub, and perhaps other scripts are needed, and if they were wrapped in a Debian package, then the production AMIs could be fully automated from whithin the Debian operating system. All of the configuration file customizations that were necessary to setup those images are inside my git repository here: https://github.com/tomheady/ec2debian Instructions on how to manually create the images are here: https://github.com/tomheady/ec2debian/wiki/64bit-ebs-ami-pvgrub I am using debootstrap to create the images from scratch. I am still a beginner in the field, but if help is needed, I volunteer to co-maintain such a package. The files and instructions are there, if you want to create a .deb for it, hack away! Feel free to let me know if any of my setup instructions are unclear. Tom -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2f548c.3060...@punch.net
Bug#594907: ITP: kspsig -- Key Signing Party signature verification tool
Package: wnpp Severity: wishlist Owner: Tom Marble * Package name: kspsig Version : 0.1 Upstream Author : Tom Marble * URL : http://github.com/tmarble/kspsig * License : GPL-3 Programming Lang: Python Description : Key Signing Party signature verification tool If you are concerned about the hash algorithm strength used in key signing this tool seeks to answer questions you may have following a key signing party... - How strongly did others sign my key? - How strongly did I sign other's keys? - How strong are the signatures for my key? This tool only reads keyrings: it does not do any key modifications. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100830154113.28001.69101.report...@ontologie.info9.net
Re: Attracting new volunteers to Debian using stackoverflow.com
On Tue, Dec 22, 2009 at 11:09 AM, George Danchev wrote: > There is no better ad than the Debian swirl itself. > > P.S. this discussion is probably best suited for -project. > Thanks for the response, you're right, I'll post this in -project, we can discuss it there. Tom -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Attracting new volunteers to Debian using stackoverflow.com
On Sun, Dec 20, 2009 at 12:49 PM, Harry Rickards wrote: > 2009/12/20 Tom Feiner : >> Hi, >> >> stackoverflow.com, which is a website featuring questions and answers on >> a wide range of topics in computer programming, has just offered [1] >> free advertising for open source projects wanting to advertise >> recruiting of new volunteers. >> >> They get about 1 million page-views per day from developers, so asking >> for new volunteers in stackoverflow.com will raise awareness of debian >> needing new maintainers. >> >> What do you think? Should we offer a Debian related ad? >> > <...> > > Definitely IMHO. We should definitely beat the Evony ad. :) :) Does anyone know a graphic designer or someone that can whip up a nice ad which will attract developers to debian? Tom Feiner [1] http://blog.stackoverflow.com/2009/12/free-vote-based-advertising-for-open-source-projects/ [2] http://stackoverflow.com/ [3] http://en.wikipedia.org/wiki/Stackoverflow.com signature.asc Description: OpenPGP digital signature
Attracting new volunteers to Debian using stackoverflow.com
Hi, stackoverflow.com, which is a website featuring questions and answers on a wide range of topics in computer programming, has just offered [1] free advertising for open source projects wanting to advertise recruiting of new volunteers. They get about 1 million page-views per day from developers, so asking for new volunteers in stackoverflow.com will raise awareness of debian needing new maintainers. What do you think? Should we offer a Debian related ad? Thanks, Tom Feiner [1] http://blog.stackoverflow.com/2009/12/free-vote-based-advertising-for-open-source-projects/ [2] http://stackoverflow.com/ [3] http://en.wikipedia.org/wiki/Stackoverflow.com signature.asc Description: OpenPGP digital signature
Re: /var/www is depracated, which directory to use?
Hi, > On Wed, Nov 4, 2009 at 5:12 PM, Holger Levsen wrote: >> Hi Tom, >> >> On Montag, 2. November 2009, Tom Feiner wrote: >>> Is /var/cache really such a bad option? I mean, the entire web content >>> is re-generated from templates & graphs are re-generated from the rrd >>> databases every 5 minutes. So even if someone did delete the directory, >>> it'll just be recreated up to 5 minutes later. >> It might be bad if the directory is gone and the webserver refuses to start >> because of a non-existing DocumentRoot... >> Well, all we're doing is defining an alias with a DocumentRoot and at least in apache2, it handles it gracefully, returning a 404 Not Found 'The requested URL /munin/ was not found on this server'. Also, apache restarts work fine. We will have to test it with the rest of the major webservers to make sure they're also ok with this, but I expect it'll work the same. Tom signature.asc Description: OpenPGP digital signature
Re: /var/www is depracated, which directory to use?
On Mon, Nov 2, 2009 at 3:48 PM, Stig Sandbeck Mathisen wrote: > Tom Feiner writes: > >> Is /var/cache really such a bad option? I mean, the entire web content >> is re-generated from templates & graphs are re-generated from the rrd >> databases every 5 minutes. So even if someone did delete the >> directory, it'll just be recreated up to 5 minutes later. > > Apart from "it feels wrong", no. Hm... it does feel a bit wrong, but do we have any other sensible choice? Adding /var/lib/munin-www/ is also an option, but it feels just as bad as /var/cache :) > >>> One could ask via debconf, and suggest /var/www/munin as a default, >>> would that be acceptable? >> >> Users might not know a good answer such a question and will probably >> just stick with the defaults, so suggesting /var/www/munin will just >> keep the current non FHS complaint status quo. > > Ok, debconf question with /var/cache/munin/html as default, then. The > admin then have the option to use /srv/foo/whatever or /var/www/munin. > > By debconf, we have a path which we'll add to /etc/munin/munin.conf, and > to the web server configuration snippets. Sorry for the newbie question (I'm not that familiar with debconf). Will debconf be able to manage upgrade from current munin version? Changing the current 'htmldir /var/www/munin' to the new user specified one? > > Should the web configuration be enabled by default? Assume apache2, and > add configuration to /etc/apache2/conf.d/munin.conf? > In phpmyadmin package they raise a debconf question, asking which web server the user wants to configure phpmyadmin to run under (and they give apache2,lighttpd options), maybe we can do the same in munin? Can you help me implement this for the munin 1.4~svn release for debian experimental? Thanks, Tom Feiner signature.asc Description: OpenPGP digital signature
Re: /var/www is depracated, which directory to use?
On Mon, Nov 2, 2009 at 2:30 PM, Stig Sandbeck Mathisen wrote: > All munin needs is a place to write static html and png files. > > * /var/lib/munin is already used as top level for munin's data files. > If we add a web root there, it may cause collisions. > Right. > * /var/cache may not be the best place, since FHS says that data here > can be deleted with little consequence, and the generated web pages > will be gone until the next time munin-graph and munin-html runs. Is /var/cache really such a bad option? I mean, the entire web content is re-generated from templates & graphs are re-generated from the rrd databases every 5 minutes. So even if someone did delete the directory, it'll just be recreated up to 5 minutes later. > > One could ask via debconf, and suggest /var/www/munin as a default, > would that be acceptable? Users might not know a good answer such a question and will probably just stick with the defaults, so suggesting /var/www/munin will just keep the current non FHS complaint status quo. Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Re: Packages that download/install unsecured files
Philipp Kern wrote: > On 2009-09-18, Tom Feiner wrote: >> Looks like this method works well for clamav-data and other similar packages >> which needs to update databases frequently on stable/oldstable. > > clamav-data is scheduled for deletion as soon as volatile moves onto > ftp-master, so that's no precedent. (I.e. there is opposition against > daily builds entering the archive without real developers signing them.) > Ah, I was not aware of this. So what is the best practice in this case, where a package needs an updated database on a regular basis (monthly basis in case of geoip)? Thanks, Tom Feiner signature.asc Description: OpenPGP digital signature
Re: Packages that download/install unsecured files
Michael S Gilbert wrote: > you could host just the hashes for the external files (signed with > your key) on your site. then you wouldn't have to duplicate > upstream's data files nor spend (much) of your own bandwidth (since > the hash files should be fairly small in most cases). > > or maybe there could be a hash.debian.org or a project on alioth to > centralize the hashes? At least for the geoip package, there's no need for a DD to take the binaries from upstream, and sign so that the package can validate it upon download. Geoip upstream provides the source of these binary databases, so all we need to do is find a consistent and reliable way to get new database updates, built from source by debian and propagated through the usual apt repositories. This looks like a good candidate for volatile/backports. Looks like this method works well for clamav-data and other similar packages which needs to update databases frequently on stable/oldstable. Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Re: Packages that download/install unsecured files
Patrick Matthäi wrote: > In the case of geoip it is just a data file (like a .svg etc) with no > attacking vector. The attacker could only inject a corrupted database > and geoip will throw errors/false positions. > > Is this realy a vector for it? > I think it there is an attack vector for it. What the example update scripts (debian/scripts/geolite*.sh) in the geoip package do is basically: wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz | gunzip Anyone who has access to the DNS server used in order to resolve geolite.maxmind.com can cause the script to download malicious code. And even though the script does not execute the code, it does use wget to download it, and pipes it through gunzip. If any unknown security vulnerabilities exist in either wget/gunzip/libgeoip then it's possible to use this as an attack vector - especially if the user puts this script in cron under the root user. (There are probably many more ways to attack, but this is the most obvious way). I hope this clarifies why I think we should find a better solution to this issue. Regards, Tom Feiner signature.asc Description: OpenPGP digital signature
Re: Bug#534429: ITP: haskell-utf8-string -- Haskell Library for operating on UTF8 strings
Erik de Castro Lopo writes: > Package: wnpp > Severity: wishlist > Owner: Erik de Castro Lopo > > > * Package name: haskell-utf8-string > Version : 0.3.5 > Upstream Author : Galois Inc. > * URL : > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string > * License : BSD > Programming Lang: Haskell > Description : Haskell Library for operating on UTF8 strings > > A UTF8 layer for IO and Strings. The utf8-string package provides operations > for encoding UTF8 strings to Word8 lists and back, and for reading and > writing > UTF8 without truncation. > Hi, this is the same as libghc6-utf8-string-dev isn't it? -tom -- Let's just hope that all the world is run by Bill Gates before the Perl hackers can destroy it. -- Erik Naggum -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530666: ITP: imagevis3d -- desktop volume rendering application for large data
Package: wnpp Severity: wishlist Owner: Tom Fogal * Package name: imagevis3d Version : 1.0rc1 Upstream Author : ImageVis3D developers * URL : http://www.imagevis3d.org/ * License : MIT/X Programming Lang: C++ Description : desktop volume rendering application for large data ImageVis3D is a volume rendering application specifically designed to render large data. This is achieved by splitting the dataset multiple levels of detail (LoD), which each level itself decomposed into multiple bricks (atomic rendering primitive). Interaction occurs at the coarsest LoD, which can be rendered instantaneously on almost all modern systems. After a configurable delay, ImageVis3D will successively render finer levels of detail, until the data are visible at their native resolution. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: US mirror troubles
I get the same thing as well. Lots of my machines hang on pulling package lists sometimes, and they hang for sure on package updates. Tom On Wed, Sep 05, 2007 at 08:41:51PM -0500, John Goerzen wrote: > Hi, > > 35.9.37.225, in http.us.debian.org, and ftp.us.debian.org, has been > unreachable on port 80 from all the networks I have access to for days. > > This is ftp.egr.msu.edu. > > It is also still listed at http://www.debian.org/mirror/list > > It is listed "bad" at http://mirror.debian.org/status.html > > Can someone remove it from http.us.debian.org and the list until it's back? > > Also, would it be possible to notify mirror admins of bad mirrors > autoamtically in the future, so this problem can be avoided? > > Meanwhile, I can't seem to find a list of rsyncable US mirrors anymore. Does > anyone know where that list is kept? > > I'm not sure what list is best for this. Apologies if I found the wrong one. > > (Should it be -project? Some ticket with the admins RT?) > > Thanks, > > -- John > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is bug #399214 release critical? (Upgrade from version not in debian currently)
Is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399214 release critical? The version of solfege in etch fails to upgrade from a version that does _not exist_ in neither stable, testing or sid now. It was a version that earlier was in testing, but has been replaced by a more recent version. -- Tom Cato Amundsen <[EMAIL PROTECTED]> http://www.solfege.org/ GNU Solfege - free ear traininghttp://www.gnu.org/software/solfege/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, 27 Feb 2006 14:48:51 -0800 Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Stephen Gran <[EMAIL PROTECTED]> writes: > > > Well parroted. Since I can see you don't understand the difference > > between main and contrib, I will point you to it. Please see 2.2.1 and > > 2.2.2 in policy. If you diff the first set of bullet points that lay > > out criteria for main and contrib, you'll see that the only differnece > > is that packages in main : > > "must not require a package outside of main for compilation or execution > > (thus, the package must not declare a "Depends", "Recommends", or > > "Build-Depends" relationship on a non-main package)" > > This is not a complete list. It may not require a package outside of > main for compilation or execution. One consequence of that, is that > it must not Depend on such packages. But this is not the *only* > consequence, it is merely the one being spelled out. > > It is certainly not true that a package in contrib can be moved to > main just be removing the package dependencies. The further question > is: can it be run without the non-free software? > > I still am not sure, having not yet received a complete answer to the > factual questions I raised. (Adam gave recently a partial answer, but > I'm still not clear on the facts to which he was alluding.) > > > Do you see a Depends, Recommends, or Build-Depends on non-free or > > contrib software somewhere in the ndiswrapper source or binary packages? > > I don't. So why is there an argument for changing it? Since there is > > no foundation in policy, do the benefits or technical merits (of which > > exactly none have been presented) outweigh ignoring a rather clear > > statement from policy? > > The question is not whether there is such a dependency declared; the > question is whether the software is useful without the use of non-free > software. > > At first blush, it looks as if the only purpose of the software is to > run NDIS drivers. So the question is: are all NDIS drivers non-free > software? (Actually, the question is slightly more complex, so please > see the previous message in which I gave a more full version of that > question.) I am not a DD, so maybe my opinion is idiotic. But: the thing is free, it allows people to use non-free drivers, but it is entirerly up to the user to use those drivers. I don't know, but for me this discussion is pointless. Does ndiswrapper require non-free packages? no. if the user decides to use non-free drivers, then it's his choice, not debian's, so what. and no, I don't care much, because i do not use ndiswrapper, but this is starting to get silly. > Thomas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329631: ITP: binutils-msp430 -- Binutils files for the Texas Instruments MSP430 family of microprocessors
Package: wnpp Severity: wishlist Owner: Tom Parker <[EMAIL PROTECTED]> * Package name: binutils-msp430 Version : 2.16 Upstream Author : FSF (well, I'm fairly sure they're the main copyright holders) * URL : http://www.gnu.org/software/binutils/ * License : GPL Description : Binary utilities that support TI's MSP430 The programs in this package are used to manipulate binary and object files that may have been created for TI's MSP430 architecture. This package is primarily for MSP430 developers and cross-compilers and is not needed by normal users or developers. (Text for description is mostly copy+paste from binutils-avr) I'm not currently a Debian developer, but have considered becoming one when a package that I particularly wanted turns up. I've made preliminary versions of this package available at http://tevp.net/debian/ and intend to search for a sponsor. -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (990, 'stable'), (103, 'testing'), (102, 'unstable'), (99, 'experimental'), (98, 'hoary'), (97, 'breezy') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Thomas Womack <[EMAIL PROTECTED]> writes: Do you have libgmp2-dev or libgmp3-dev installed? I have libgmp2, libgmp3 4.0.1-3 and libgmp3-dev 4.0.1-3, so you're using later versions of all the relevant packages (indeed, since you're on amd64, on entirely different hardware) and the bug is still there. I've also reported it to [EMAIL PROTECTED] on general principle, though have heard nothing from them yet. I've just checked that this wasn't a stupid problem to do with missing mpz_init() commands; if you insert mpz_init(A); mpz_init(B); mpz_init(C); before the first mpz_urandomb() call, it still segfaults in the same place. Tom
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: > freedesktop entry features > debian menu file features > > Therefore you can do a lossless transition from .desktop to menu, but not > the other way around. It makes sense to use the .desktop standard. I know what you mean, but don't you mean "lossless transition from menu to .desktop" ? .desktop is the one that has more features, so a transition from .desktop to menu would lose. It's trivial but I might not understand the issues if its the opposite.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 01:12:13AM +, Colin Watson wrote: > . Could you please try > to keep debian-devel posts to well-thought-out [1] technical content, Sure. I'd also ask everyone to keep their anti-American, anti-Bush SIGs and random comments out of both lists. I have acted like a jackass on purpose -- to give you a taste of what it feels like to put up with incessant opinions which you find illogical. How about a cease-fire on both sides of the idological debate? But I decided to cut down on the opinion posts; these are just reverberations from people catching up.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 11:45:58PM +1100, Russell Coker wrote: > > As for acting like a Jackass, the Johnny Knoxville and his colleagues are > very > talented entertainers who work hard. I wouldn't compare them to you in any > way. Oh, I dunno. I got *your* attention. But chill the hell out. I'm disengaging. My point (such as it is) is accomplished. Nothing but technical matters from me from here on. Save the bitching for next time.
Re: OT: Smartcards and Physical Security
On Sat, Dec 06, 2003 at 11:13:05AM -0600, Manoj Srivastava wrote: > And then again I question your judgement. What, pray, is this > good thing that is going to go away? "Hey hey I saved the world today Everybody*s happy now The bad things gone away And everybody*s happy now The good thing*s here to stay Please let it, please let it" I'm not being evasive, this is the answer to your question: You'll know it when it's gone.
Re: OT: Smartcards and Physical Security
On Sat, Dec 06, 2003 at 01:51:23AM -0600, Manoj Srivastava wrote: > > Drop the imperatives, and we shall get along a lot better. > Better still, roll up your sleeves and make it happen, and > you'll earn my respect, and my support. How about "fuck up again and watch your good thing go away" (hint I ain't it) > I was merely dumbfounded at the _quality_ of pot shots you > were taking. Heh. I've had to tell people at work to go home and take a fucking bath: you stink. Manoj, your words are powerless.
Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)
On Fri, Dec 05, 2003 at 11:36:20AM -0400, Ben Armstrong wrote: > Then that discussion needs to be resolved so that a solution can be made > that is in Debian main. It's useful to try to clarify the terms so people can speak the same language, but as soon as you categorize anything somebody's going to come out with something which fits in multiple categories. Anything which isn't just a subset of Debian will ultimately just be a distraction, in which case the # of "flavors" is the cardinality of the power set of packages. :-)
Re: OT: Smartcards and Physical Security
Let me start by saying I basically understand your last point: it's not worth it because it won't work. On Fri, Dec 05, 2003 at 04:01:42AM -0600, Manoj Srivastava wrote: > who follow secire processes. Blowing 40k collectively is unlikely to > buy us much security. Like I said, it may be that it would be wasted money. But you are switcing arguments here. Originally you were bristling at the suggestion that you spend your own money. Now you seem to be okay with that, but saying it would be wasteful because you basically don't trust smartcards. I don't trust them either, but they are a layer. Of course, they may be an absolutely useless layer, but they may not. I think this is your true objection (to smartcards at all) and not to the suggestion of having your spend your own money to improve the project. And that's an acceptable belief (although it *may* not be correct). But if you want to explore other, free ways to improve Debian's security process (such as auditing one another's machines or some other way I can't think of), that's a good thing. The point is: a failure occured. Don't let it happen again. > > >> Let me see if I can point out the logical flaws in words with few > >> syllables. > > Take a bath? take a _bath_? What are we, back in grade school now? You're not seriously talking about taking pot shots are you? Tit for tat. But I withdraw the remark, I was thinking of the traditional image of the long-stringy-haired Unix hacker such as RMS. I was picturing RMS -- I didn't mean anything else. :-)
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 06:13:49PM -0500, Matt Zimmerman wrote: > > Not really; he just has to set things up ahead of time. This is like > claiming the attacker has to be present in order to sniff your password from > a telnet session (he doesn't; he just has to have been around at any time > before then in order to set up a sniffer). That's totally true. It's not the way this attack happened though. All I know is it's a layer and experts say layered defense is best. I still think it would discourage the cracker. A lot of the "open a netcat over the exposed pipe" tricks wouldn't work iff the smartcard auth stack wasn't compromised -- the netcat couldn't get auth'd, and the server wouldn't buy it. The problem now is a pipe is a pipe. Just rambling... I'm sure there's tons of holes in what I just said.
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 02:23:54PM -0500, Matt Zimmerman wrote: > On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote: > You must be joking. If the developer's system is compromised, and he logs > into another system after that time, that system can be easily compromised > also. Yes, but the reason it would have been efficiacious in this *particular* instance is the hacker sniffed the password, and then logged on to Debian's servers later at his leisure from a different PC. With a smartcard, he would have had to done it *on* the Dev's infected PC *while* the smartcard was plugged in. In theory the smartcard would not be plugged in all the time, thus diminishing the attack surface.
Re: OT: Smartcards and Physical Security
On Thu, Dec 04, 2003 at 11:43:21AM -0600, Manoj Srivastava wrote:
> Snippy, aren't we? Usually it is better to have basic logic
> straight before you try for a mistaken sense of haughtiness.
My logic is correct; apparently my understanding of the goals of the
Debian project is not. I always thought it was first and foremost for
the devs themselves ("we don't care if anybody uses it but us"). Under
that reasoning, I'd think you'd *want* to spend money to have the best
for yourselves. The second and lesser reason is as a benefit for
society -- thus the comparision to the orgs you say are not like Debian
at all.
But primarily I would have thought you'd really want to have the best
environment in the world. I'm not saying you don't want that, I just
didn't realize $30 would be a showstopper, especially since as you say
you are already contributing so much.
But that's just me.
>
> Let me see if I can point out the logical flaws in words with
> few syllables.
Um, yeah. Take a bath.
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 11:14:29PM +0100, Wouter Verhelst wrote: > > Let me reiterate. You want to set up something with the Debian Project's > machines so that I have to pay for the privilege of contributing? > > Thanks, but no thanks. Volunteers don't work that way. > No sweat, that's totally cool. In other circumstances and for other ends, some groups of people *might* feel compelled to sacrifice. But that's probably not even necessary here. I was just being clever. It's not like it's an absolute requirement, anyway. One day they will tear down the internet, sequence everybody's DNA, and rebuild it proper. Then we'll chill :-)
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:24:07AM -0600, Manoj Srivastava wrote: > Heh. Your grasp of the practicality of the situation is > slipping. Not only do these guys donate a fairly expensive chunk of > billable hours and expertise, they must pay to be able to volunteer? Sure, if you care about security.
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:26:15AM -0600, Manoj Srivastava wrote: > Guess what the median age of a Debian developer is. Don't know, don't care. > Volunteer organization have dues? Yes, I don't know what planet you're from, but on this planet the Rotarians, Kiwanas, Civitans, Knights of Columbus, United Way, Red Cross, Freemasons, NAACP, and Jerry's Kids all collect money from their members. You still feeling superior?
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:28:30AM -0600, Manoj Srivastava wrote: > Sender: Tom Ballard <[EMAIL PROTECTED]> Yeah, somebody else pointed that out. It's bullshit that mutt was doing that to me. My /etc/email-addresses: # This is /etc/email-addresses. It is part of the exim package # # This file contains email addresses to use for outgoing mail. Any local # part not in here will be qualified by the system domain as normal. # # It should contain lines of the form: # #user: [EMAIL PROTECTED] #otheruser: [EMAIL PROTECTED] tom: Tom <[EMAIL PROTECTED]> So I thought I was covered, and my .muttrc never showed it. I fixed it. Like I said, I never thought I'd have to lie to Linux, but there you are.
Re: OT: Smartcards and Physical Security
On Wednesday 03 December 2003 15:32, Manoj Srivastava wrote: > An even better security guideline is "something you are" -- so > should we not spring for retinal scanners/fingerprint readers/other > buiometrics? I mean, we _are_ talking about other peoples money. :P However 'something you are 'always gets turned into 'something you are not' (in electronic form) which can be copied, and be re inserted between the end point and the biometric device. One advantage to smart cards that i think may have been missed in the discussion (correct me if im wrong) is that not all the information leaves the device, they actually do processing on the smart cards themselves and it is physically difficult (i.e cant be done in a non detectable way) to read the keys protected in this manner. Its more complicated than this in reality but that kind of gives the jist of why smart cards are _much_ better than magnetic strips for instance. Tom -- ^__^| Tom Badran (oo)\__ | Imperial College (__)\ )\/\| Department of Computing ||w || --- || ||| Using Debian SID pgpwrVEhZvy8M.pgp Description: signature
Re: Install Images
On Wednesday 03 December 2003 18:12, Andreas Metzler wrote: > http://freedesktop.org/~daniel/d-i/ > cu andreas You star ;) Thanks Tom -- ^__^ | Tom Badran (oo)\__ | Imperial College (__)\ )\/\| Department of Computing ||w || --- || ||| Using Debian SID pgpQ49PglrOcI.pgp Description: signature
Install Images
Is there anywhere i can download debian-installer beta images (im getting a new laptop tommorow), prefereably with support for reiserfs filesystems? Gluck still isnt working and i cant seem to find mirrors anywhere. Thanks Tom -- ^__^| Tom Badran (oo)\__ | Imperial College (__)\ )\/\| Department of Computing ||w || --- || ||| Using Debian SID pgpg1D2FLjlBS.pgp Description: signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 09:06:07AM -0600, Graham Wilson wrote: > > So you've aided telemarketers and worked for Microsoft? Is your last > name Darkness, middle name Prince of? Satan fell because he wanted to know. So do I. I'm a contrarian. I believe the opposite of whatever I'm confronted with at the moment. Evil is when you look around your life and say: "man, I gotta get some new friends." :-)
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote: > > Share the crack. In my experience kids in college and right out tend to freak out over the thought of having to spend a few dollars of disposable income, because they don't have any :-) Hey, laugh if you want, most organizations have dues, it's not unprecedented in human history :-)
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Thu, Dec 04, 2003 at 12:20:57AM +1100, Hamish Moffatt wrote: > > How about including your full name somewhere in your posts too then? > I find it a bit off-putting to discuss security with someone who's > obscuring their identity. Ha Ha Ha what a joke. I don't want to be googled for all eternity. Let me tell you a story about a job I had one time: I worked for a guy (in his basement -- don't ask) who bought your personal credit card data and other publicly available information. He would pay about $10,000 or $15,000 for lists of ~100,000-200,000 people's data. My job was to datamine it under criteria like: Give me all the people who make between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain area, and used their Visa more than 10 times on the boat within the last 6 months. We'd rank order the data, apply the filter, and maybe get 10,000 good names, which he would sell for about $140,000 to a home alarm company, who would then call you during dinner. [1] Another job I had was for a drug testing company. My job was to write the report processing system which would say "You Person X have Tested Positive for Drugs A, B, and C and you are fucked." At one point in 1994 I had 40,000 people's drug test results on my 486SX-50. Just for grins I did a group by query, grouping drug frequency by a company's SIC industry code, and sorting in descending order. The most frequent people to test positive for drugs are construction workers, marijuana and cocaine. The next most frequent are school employees (probably bus drivers) testing positive for alcohol. Everything else was kind of evenly distributed. And you wonder why I am concerned with my identity!!! [1] I finally told the guy to go pound sand. I said: "You'd be more useful to society if you just grow corn or something." Doing that type of work made me want to slit my wrists.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:10:28PM +0100, Wouter Verhelst wrote: > > Are you going to pay for all those smartcards plus their readers? > Including any smartcards for possible future DD's? > > If not, I suggest we forget about this, as it won't be feasible. I don't think the USB models cost that much (maybe $50-$100 ea. in bulk). My badge at Microsoft was my smart card. The devs themselves could pay part of the cost, with perhaps partial donations from a corporate sponsor. I think even a college student could find $50 for this. The other guys suggestion about RSA tokens was better. I think they are probably only $15-$25, because they don't connect to your PC. Anyway, feel free to forget about it. It was just a suggestion.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote: > > What is a "RSA token"? > Device used in some internet banks. You have a device, which has only > chipset, digital pad with on/off switch and display, all embedded in small > case. Authentication is made using C/R algorithm: you receive a number > from system, enter it into token, chipset signs it using stored RSA key, you > get a number from display and use is as a password. Yeah, these are good: they're cheap and I think it would have been effective at preventing this particular incident. That's an excellent idea.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: > > If something could have prevented something that actually happened, I > say go for it. Oh, one last thing: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? This is a big deal.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote: > [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into > private > mail, but your e-mail address was munged in some sort of anti-spam > measure, and not trivially un-mungeable. Please consider providing > information on how to demunge it in some X- header, or not using > munging at all.] Heh. That's my actual email address. Fooled ya. > Well, the DD can't log in without the smart card, so that's clearly a > prerequisite. You leave it unplugged until you need it, do your thing, then unplug it. Sure, I could still infect your toolchain so you unwittingly upload trojaned stuff. But the fact is in this *actual* compromise the password was stolen and the hacker worked later at his leisure: smartcards would have prevented this *actual* incident (but of course doesn't prohibit other ways of attack). If something could have prevented something that actually happened, I say go for it.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote: > On Tue, 02 Dec 2003, Tom wrote: > > Yes but the attacker did not "steal" the DD's computer. He rooted it > > remotely. > > So the machine is rooted remotely, the DD logs into a debian box even > using our new fangled smart cards, and the attacker still can control > the connection. Not while the smart card isn't inserted. > > In this particular intrusion vector, the use of a smart card merely > means that the attacker has to trojan the ssh binary on the > compromised machine and use it to run a command that opens a shell > under the DD's uid on a non-privledged port, thus circumventing the > smart card in its entirety. I don't understand this objection, but it seems valid. Could you explain? > > If you log into a machine from a compromised machine using any means I > can forsee today, the attacker can always control the account of the > machine logged into, because the attacker effectively become the user > of the machine. > Yes, I always warned my employer that all I have to do is own your machine before you plug in your smart card, leave a logic bomb to do something while you're connected, wait for you to hang up and then report back. But it's all layers, layers, layers. More layers = better, none is a panacea. Have you ever used smartcards? I think that the more layers the better.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Tue, Dec 02, 2003 at 05:34:05PM -0800, Don Armstrong wrote: > On Tue, 02 Dec 2003, Tom wrote: > > I think the DD's should seriously think about requiring smartcards. > > It would have prevented the proxmiate cause of our recent troubles. > > Smartcards are not a magical panacea either. The problems associated No, they're not. Security is all about layers of defense. > with them aren't too terribly different from those associated with > keys or other forms of physical security, notably, that they can be > stolen, or the output from them duplicated. Refer to the ongoing saga > between DirectTV and satelite pirates for a trivially applicable > example. Yes but the attacker did not "steal" the DD's computer. He rooted it remotely. It is true that a shitty smartcard which is only dumb storage for a private key is no better than storing your keys on an USB keyring. Good smartcards never transfer the key off the card. The smart card can be compromised itself true. Repeat: Security is about layers of defense. Multiple things have to be compromised. > > From my perspective, Smartcards do little to raise the bar. They > merely move the bar sideways. You're wrong. They're better.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: > On Wed, Dec 03, 2003 at 11:17:19AM +1100, Russell Coker wrote: > > The only way to have avoided this kernel vulnerability from day-0 of > discovery/fix release would have been to be constantly upgrading to > pre-release kernels. > > I'm starting to sound like I'm trolling for closed-source development models > or something, which is not the case, Smartcards would have avoided the Debian compromise: merely having a compromised DD box would have prevented bad guy from getting on the box. It's all about layers of defense. I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 11:46:45PM +, Geoff Richards wrote: > > South of where? USA. North Carolina. Not South Carolina. Remember that. Redhat is in North Carolina. I always wonder if those mascara-wearing Cure-listening long-haired Linux skater punks ever get into trouble out in those Redneck bars. There's poofter places around but it's kind of hard to avoid trouble indefinitely. I learned you need to wear big shit-kicking boots and they ignore you. If you're openly "superior", trouble always follows. You got klansmen, constructions, crackheads, iterant workers, and marines. SC is worse. Tennessee is worse still. And North Florida they'll leave your ass in the swamp. > As far as security goes, we have to take 'dangerous' to mean > exactly that, diminutive or not. But if it didn't look like > a vulnerability then we can't blame anyone for missing it. Yeah, it was purely a misreading on what he said, no need to pile on *that* guy. But blame or not if a real showstopper gets out in future, it's not good!
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 08:51:50PM +0100, Andreas Rottmann wrote: > Tom <[EMAIL PROTECTED]> writes: > > > On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: > >> rather far from changing anything in the kernel memory. Andreas is > >> definitely right that the hole doesn't look like that it is that dangerous. > > > [snip] > > > > If it wasn't a big deal we wouldn't be talking about it. It shut down > > servers. It's dangerous enough. > > > Note the "looks like". I read all the words but took a completely different meaning :-) I'm from the South, we have different speech patterns... "the hole doesn't look like that it is that dangerous" means something different than the hole doesn't look like that it is dangerous" in my ears ... "that" is diminuitve in my dialect if you don't put emphasis on it :-)
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: > rather far from changing anything in the kernel memory. Andreas is > definitely right that the hole doesn't look like that it is that dangerous. It messed up your life for a couple weeks. Jesus, it's not the end of the world, but that's the way Microsoft (used to | still) thinks. If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough.
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 02:20:43PM +0100, Goswin von Brederlow wrote: > There is no security as strong as many people reading the source over > and over. You can't hack their brains to skip over the backdoor code > and you can only obfuscate a backdoor so much. Allright, allright, I'll cry uncle. /me standing way over here on the outside sure is noticing a lot of ruckus for something that isn't a problem :-)
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 01:17:58PM +0100, Goswin von Brederlow wrote: > Tom <[EMAIL PROTECTED]> writes: > > What precautions are taken that the DD actually signed it with the DD's > > private key? > > Set aside the possibility that the DD herself is actually the attacker. > > You never can. But once the compromise or the DD is found out it would > be easy to scan the archive for possible compromised packages audit > the sources and rebuild the binaries. Thanks for the frankness; I was asking the question pointedly. But if you fix the problem after it occurs, the damage is done. Closed source companies have ways of dealing with social engineering aspects (people wear badges; secure sources on isolated networks, security guards, threats of firing people, smart cards for SSH/VPN). I worked at Microsoft for 3 years and did some work with the security guys. The main branch of NT is about 70gb. They have a policy that any code has to be on encyrpted file system. If your laptop gets stolen with NT code on it, you get fired. If you leave your laptop in your car or check it on your airplane, you get fired.) The point of my question is: what can open source do that is comprable? It seems especially relevant considering the other thread about establishing Enterprise Debian. My nagging is just to provoke thought in the community. I don't have any answers.
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote: > * Joey Hess ([EMAIL PROTECTED]) [031202 02:55]: > > Goswin von Brederlow wrote: > > > What can we do with deb signatures? > > > > > > For our current problem, the integrity of the debian archive being > > > questioned, the procedure would be easy and available to every user: > > > > > > 1. get any clean Debian keyring (or just the key signing the keyring) > > > 2. verify the latest Debian keyring > > > 3. verify that each deb was signed by a DD and the signature fits What precautions are taken that the DD actually signed it with the DD's private key? After all this compromise was due to a DD's machine being compromised. I don't think you can audit every DD's workstation to make sure the keys are well managed. Set aside the possibility that the DD herself is actually the attacker. You have to have an answer for these remote possibilities. (Things tend to get maximally bad). > > > The canoical attack against signed debs in this situation is to find a > > signed deb on snapshot.debian.net that contains a known security hole. > > To avoid this attack, it is necessary that the filename of the deb or > the version of the package is also signed.
