Re: Bug#993488: maybe reason for wontfix?
Tomas Pospisek wrote: > I am guessing that the reason for the "wontfix" is "that's just how > Unix works unfortunately" aka "that's a Unix design bug"? Is my guess > correct? I would call it a "Unix design decision" or even an "OS design decision", because Windows (of the NT variant) has made the same decision: Not allowing changes to running programs or sessions vastly simplifies everything. (Yes, with AD you can refresh some of the memberships in a purely Kerberos environment and for local group you can use "runas" to get the new groups for a new process, but the same can be done in Unix as well.) In the then I can see the designers thinking "a change in group membership is happening not often, allowing or optimizing this use case will be a huge hassle" and thus never implemented or even mandated its existance. And now this is so baked in to everything that suddenly allowing it would break many programs, without a doubt. In the end, this tag is a more "cantfix" than a "wontfix", because you basically can't, without creating a new OS. Grüße, Sven. -- Sigmentation fault. Core dumped.
Bug#932769: [moreinfo] DoS via DHCP request
On Tue, 23 Jul 2019 19:32:04 -0600 Mark Hutchison wrote: > When I look at systemctl for the dhclient service, I can see that there's > an error, "can't create /var/lib/dhcp/dhclient.intname.leases Read Only > file system", and then the DHCPREQUEST > DHCPACK > DHCPDECLINE sequence > starts every few seconds, and occasionally the service will show "RTNETLINK > answers: File Exists." > > I'm guessing from the error that dhclient has a problem with not being able > to read / write to the client leases file, declines the IP and requests > another, but secretly holds on to the IP. > I see that someone reported this similar bug back in 2018 as well, I think > they may be the same thing. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209 > > Thanks, just let me know if you have any questions. To confirm your findings: We saw the same as well with isc-dhcp-client. As soon as the filesystem its lease file resides on becomes unreachable or read-only, it throws a fit and just hammers away at the DHCP infrastructure. In our case every client has a fixed DHCP reservation and only ever gets OFFERed the same IP, which he then declines, but when you have several hundred clients flooding DHCP reequests at the same time, the load on the infrastructure, including switches with DHCP Snooping active, is immense. I also think that #888209 is the same issue. Coincidentally it also happened in out VMware cluster when an iSCSI-backed LUN when down but you should be easily able to reproduce this with a simple local KVM setup. Grüße, Sven. signature.asc Description: OpenPGP digital signature
Re: Seeking hardening flag / blhc expoert
Andrey Rahmatullin wrote: > [-- text/plain, encoding quoted-printable, charset: utf-8, 11 lines --] > On Fri, Apr 05, 2019 at 09:07:06PM +0200, Sven Hartge wrote: >> CMake is a bit "special" in that regard. To get the right hardening >> flags to work for some parts of Bacula, we had to include the following >> patch to kind-of brute force the flags: >> https://salsa.debian.org/bacula-team/bacula/blob/master/debian/patches/debian/enable-hardening-for-qmake > qmake != CMake. Yes, I noticed this the moment I hit sent. Must have been more tired than I thought I was yesterday. Grüße, Sven -- Sigmentation fault. Core dumped.
Re: Seeking hardening flag / blhc expoert
Otto Kekäläinen wrote: > I've read this section many times over but I don't get it. A > workaround is presented but since we are on a new debhelper it is > advised not to be used. It suggests using > /usr/share/dpkg/buildflags.mk but since we already call default.mk the > buildflags.mk should be included. There are some variables set, but > since the cmake command does not include them, changes in them does > not have an effect. There is no explanation about that flags do what > and which are the relevant ones, so blindly just defining everything > does not seem like a savvy solution. CMake is a bit "special" in that regard. To get the right hardening flags to work for some parts of Bacula, we had to include the following patch to kind-of brute force the flags: https://salsa.debian.org/bacula-team/bacula/blob/master/debian/patches/debian/enable-hardening-for-qmake , | --- a/src/qt-console/bat.pro.in | +++ b/src/qt-console/bat.pro.in | @@ -187,3 +187,9 @@ | QMAKE_EXTRA_TARGETS += depend | | TRANSLATIONS += ts/bat_fr.ts ts/bat_de.ts | + | +### See https://wiki.debian.org/Hardening#Notes_for_packages_using_QMake | +QMAKE_CPPFLAGS *= $(shell dpkg-buildflags --get CPPFLAGS) | +QMAKE_CFLAGS *= $(shell "dpkg-buildflags --get CFLAGS; dpkg-buildflags --get CPPFLAGS") | +QMAKE_CXXFLAGS *= $(shell "dpkg-buildflags --get CXXFLAGS; dpkg-buildflags --get CPPFLAGS") | +QMAKE_LFLAGS *= $(shell dpkg-buildflags --get LDFLAGS) `[...] The rules file https://salsa.debian.org/bacula-team/bacula/blob/master/debian/rules just contains the usual: , | # enable bindnow | # https://wiki.debian.org/HardeningWalkthrough | export DEB_BUILD_MAINT_OPTIONS = hardening=+all | | # avoid unnecessary linking | # https://wiki.debian.org/HardeningWalkthrough | export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed ` Maybe this gives you a hint at what to do and where. S! -- Sigmentation fault. Core dumped.
Re: confused about virtual build-depends libcurl-dev
Sven Hartge wrote: > Sven Hartge wrote: >> I changed the resolver to use a combination of mk-build-deps and >> aptitude, the same as sbuild and pbuilder use to resolve build-deps, to >> better handle alternatives. >> You may have hid an edge case I didn't encounter during my testing. > Hmm, I may see the reason for your problem. I'll need to run some tests > with the Salsa-CI pipelines to check if my hunch is correct. Should my > assumption be correct, I will fix this via a MR with the Salsa-CI-Team. I've reconstructed the situation to analyze it and was able to recreate the way pbuilder and sbuild install build-dependencies in the Salsa-CI pipeline context. Expect a fix for this behavior soonish, after I concluded my final tests. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: confused about virtual build-depends libcurl-dev
Sven Hartge wrote: > I changed the resolver to use a combination of mk-build-deps and > aptitude, the same as sbuild and pbuilder use to resolve build-deps, to > better handle alternatives. > You may have hid an edge case I didn't encounter during my testing. Hmm, I may see the reason for your problem. I'll need to run some tests with the Salsa-CI pipelines to check if my hunch is correct. Should my assumption be correct, I will fix this via a MR with the Salsa-CI-Team. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: confused about virtual build-depends libcurl-dev
Thomas Koch wrote: > We're trying to package nix. Its d/control[1] currently says: > build-depends: libcurl4-gnutls-dev | libcurl4-openssl-dev | libcurl-ssl-dev > When I build it on my own machines with sbuild, then it gets built > with libcurl4-gnutls-dev. On salsa it gets built with > libcurl4-nss-dev. How can there be a difference in selection? I am the one responsible for a change in the build-depdendency resolver used by the Salsa-CI pipelines. Before the change, they used "apt-get build-dep ." to gather the build-deps, but this didn't work for *-backports or experimental or Jessie. Also it would pull in recommended packages, which could make the build unreproducible and is agains Policy 4.2. I changed the resolver to use a combination of mk-build-deps and aptitude, the same as sbuild and pbuilder use to resolve build-deps, to better handle alternatives. You may have hid an edge case I didn't encounter during my testing. > [1] https://salsa.debian.org/debian/nix/blob/kaiha/wip/debian/control Do you have a pipeline log on Salsa showing the mis-selection of build-deps? During a cursory glance I could only find logs showing the use of libcurl4-gnutls-dev. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: usrmerge -- plan B?
Martin Steigerwald wrote: > Marco d'Itri - 23.12.18, 22:30: >> On Dec 23, Martin Steigerwald wrote: >>> I think I have seen this with either SLES or RHEL that they created >>> symlinks for every binary in /bin and /sbin, pointing to the binary >>> in /usr/bin and /usr/sbin. I did not understand why at the time I >>> have seen this. >> Definitely not RHEL, maybe you are thinking about SCO UNIX? Anyway, >> this is just a fantasy: I do not believe that a forest of symlinks >> could work for the content of /lib*. > It might have been SLES. During my holidays I am certainly not > accessing my training VMs. But I can look next year. SLES12 has this: server:~ # ls -l /bin | grep usr lrwxrwxrwx 1 root root 13 Aug 31 16:00 arch -> /usr/bin/arch lrwxrwxrwx 1 root root 17 Aug 31 16:00 basename -> /usr/bin/basename lrwxrwxrwx 1 root root 12 Aug 31 16:00 cat -> /usr/bin/cat lrwxrwxrwx 1 root root 14 Aug 31 16:00 chgrp -> /usr/bin/chgrp lrwxrwxrwx 1 root root 14 Aug 31 16:00 chmod -> /usr/bin/chmod lrwxrwxrwx 1 root root 14 Aug 31 16:00 chown -> /usr/bin/chown lrwxrwxrwx 1 root root 13 Nov 6 10:22 chvt -> /usr/bin/chvt lrwxrwxrwx 1 root root 18 Nov 6 10:22 clrunimap -> /usr/bin/clrunimap lrwxrwxrwx 1 root root 11 Aug 31 16:00 cp -> /usr/bin/cp lrwxrwxrwx 1 root root 13 Nov 6 10:22 cpio -> /usr/bin/cpio lrwxrwxrwx 1 root root 13 Aug 31 16:00 date -> /usr/bin/date lrwxrwxrwx 1 root root 11 Aug 31 16:00 dd -> /usr/bin/dd lrwxrwxrwx 1 root root 18 Nov 6 10:22 deallocvt -> /usr/bin/deallocvt lrwxrwxrwx 1 root root 11 Aug 31 16:00 df -> /usr/bin/df lrwxrwxrwx 1 root root 14 Nov 30 09:03 dmesg -> /usr/bin/dmesg lrwxrwxrwx 1 root root 17 Nov 6 10:22 dumpkeys -> /usr/bin/dumpkeys lrwxrwxrwx 1 root root 13 Aug 31 16:00 echo -> /usr/bin/echo lrwxrwxrwx 1 root root 11 Aug 31 16:00 ed -> /usr/bin/ed lrwxrwxrwx 1 root root 14 Aug 31 16:00 egrep -> /usr/bin/egrep lrwxrwxrwx 1 root root 14 Aug 31 16:00 false -> /usr/bin/false [...] server:~ # ls -l /sbin | grep usr lrwxrwxrwx 1 root root28 Aug 31 16:03 OCICLI -> /usr/sbin/OneClickInstallCLI lrwxrwxrwx 1 root root28 Aug 31 16:03 OneClickInstallCLI -> /usr/sbin/OneClickInstallCLI lrwxrwxrwx 1 root root35 Aug 31 16:03 OneClickInstallUI -> /usr/sbin/OneClickInstallUrlHandler lrwxrwxrwx 1 root root35 Aug 31 16:03 OneClickInstallUrlHandler -> /usr/sbin/OneClickInstallUrlHandler lrwxrwxrwx 1 root root23 Aug 31 16:03 SuSEfirewall2 -> /usr/sbin/SuSEfirewall2 lrwxrwxrwx 1 root root18 Aug 31 16:00 adjtimex -> /usr/sbin/adjtimex lrwxrwxrwx 1 root root16 Nov 30 09:03 agetty -> /usr/sbin/agetty lrwxrwxrwx 1 root root16 Aug 31 16:01 arping -> /usr/sbin/arping lrwxrwxrwx 1 root root17 Aug 31 16:02 audispd -> /usr/sbin/audispd lrwxrwxrwx 1 root root18 Aug 31 16:02 auditctl -> /usr/sbin/auditctl lrwxrwxrwx 1 root root16 Aug 31 16:02 auditd -> /usr/sbin/auditd lrwxrwxrwx 1 root root20 Aug 31 16:02 augenrules -> /usr/sbin/augenrules lrwxrwxrwx 1 root root18 Aug 31 16:02 aureport -> /usr/sbin/aureport lrwxrwxrwx 1 root root18 Aug 31 16:02 ausearch -> /usr/sbin/ausearch lrwxrwxrwx 1 root root17 Aug 31 16:02 autrace -> /usr/sbin/autrace lrwxrwxrwx 1 root root19 Aug 31 16:00 badblocks -> /usr/sbin/badblocks lrwxrwxrwx 1 root root15 Nov 30 09:03 blkid -> /usr/sbin/blkid [...] Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Debian CI pipeline for Developers
IOhannes m zmölnig (Debian/GNU) wrote: > On 11/16/18 3:14 PM, Kentaro Hayashi wrote: >> package repository, sure we can change the project's setting, but >> debian/.gitlab-ci.yml seems to be the proper default setting. > i don't think there is any reason to use a (hidden) dotfile in the > debian/ directory. I see one reason: If the file is named "somedir/.gitlab-ci.yml" Gitlab automatically verifies the file and presents a "This GitLab CI configuration is valid." hint (or an error message) when viewing. If the file is named differently, this does not happen. The "Custom CI config path" setting does not influence this. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Debian Stretch new user report (vs Linux Mint)
Paul Wise wrote: > On Mon, Dec 4, 2017 at 5:22 AM, Marc Haber wrote: >> Debian is also about providing an Universal Operating System, and I >> have seen BIG installations of Debian on server farms moving to >> PragBF because the Broadcom network chips on those servers required >> people jumping through hoops while PragBF just works. > Could you link to PragBF? I can't find any mention of it on web search > engines. ROT13: CentOS Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Debian Stretch new user report (vs Linux Mint)
The Wanderer wrote: > On 2017-12-01 at 16:44, Sven Hartge wrote: >> Luca Capello wrote: >>> On Fri, 01 Dec 2017 14:59:53 -0500, James McCoy wrote: >>>> People seem to be skipping over the fact that even after ntfs-3g >>>> was installed, the user only had RO access. That's the bigger >>>> issue. >> >>> Exactly, which IIRC is the normal behavior if the NTFS filesystem >>> was not properly "closed", e.g. if Windows was hibernated (or it >>> uses the Fast Boot/Startup feature, thus suspend2both). >> >> Which is normal since at least Windows 7, maybe even Vista, to not >> shutdown completely, but only shutdown the applications and then >> hibernate the remaining Windows Kernel and memory to disk, leaving >> the filesystem unclean. > Are you sure? Not on the version specifics, to be honest. > I've been managing Windows 7 at my workplace for years now, and I've > never seen this "suspend in response to Shut Down" behavior there; the > first place I ever saw it was on a Windows 8 machine. I'm not sure > I've yet seen it in our current Windows 10 pilot, either, but I also > haven't looked especially closely there. Maybe it happens only on Windows 7 on SSD? Or only in specific editions? But a quick web search reveals that Windows 8 was the first Windows to have "Fast Startup"/"Hybrid Shutdown" enabled per default and Windows 10 has this feature enabled as well. I mostly deal, if I have to deal, with the server variant of Windows, which does not have this feature. But I have seen the NTFS-mount-only-as-RO problem on other peoples systems, when dual booting into Linux. S° -- Sigmentation fault. Core dumped.
Re: Debian Stretch new user report (vs Linux Mint)
Luca Capello wrote: > On Fri, 01 Dec 2017 14:59:53 -0500, James McCoy wrote: >> People seem to be skipping over the fact that even after ntfs-3g was >> installed, the user only had RO access. That's the bigger issue. > Exactly, which IIRC is the normal behavior if the NTFS filesystem was > not properly "closed", e.g. if Windows was hibernated (or it uses the > Fast Boot/Startup feature, thus suspend2both). Which is normal since at least Windows 7, maybe even Vista, to not shutdown completely, but only shutdown the applications and then hibernate the remaining Windows Kernel and memory to disk, leaving the filesystem unclean. S° -- Sigmentation fault. Core dumped.
Re: openssl/libssl1 in Debian now blocks offlineimap?
Adrian Bunk wrote: > [1] I haven't investigated how widespread this specific problem > actually is, or whether it can be mitigated - the point is that > it is unrelated to TLS versions supported by PayPal or online > banking apps running on the device I asked on the freeradius-users list, if there is an easy way to log the SSL/TLS version a client uses during the PEAP/TTLS handshake, to get a better understanding of the situation on my universities wireless networks, but unfortunately this was not easily possible. http://lists.freeradius.org/pipermail/freeradius-users/2017-August/088521.html It would be really interesting to gather some long term statistics about this to see a trend of the adoption of newer TLS versions over time. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: OpenSSL disables TLS 1.0 and 1.1
Christian Seiler wrote: > Don't get me wrong: I do believe it's a huge problem that vendors of > said appliances don't provide updates for these kind of things, and I > wish that we could indeed drop everything except TLS 1.2, but the real > world is unfortunately more complicated, and I think Debian would do a > huge disservice to users if it removed TLS 1.0 and 1.1 from OpenSSL in > Buster without a well-documented possibility for the admin to reenable > it. I'd go one step further and say that Debian would disqualify itself as a distribution usable for any real world application. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: OpenSSL disables TLS 1.0 and 1.1
Kurt Roeckx wrote: > On Fri, Aug 11, 2017 at 01:34:53PM +0200, Sven Hartge wrote: >> Marco d'Itri wrote: >>> On Aug 09, Sven Hartge wrote: >> >> Looking at https://developer.android.com/about/dashboards/index.html >> >> there is still a marketshare of ~25% of smartphones based on Android >> >> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the >> >> moment) block ~40% of Android smartphones from connecting to any WLAN >> >> using PEAP or TTLS. >> >> > Android 5.x should support TLS 1.2: >> > http://caniuse.com/#search=TLS >> >> The Browser, yes. But not the components doing the WPA stuff: >> >> , >> | Aug 9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: >> TLS Alert write:fatal:protocol version): [owehxperia] (from client ap01 port >> 54 cli 30-39-26-xx-xx-xx) >> | Aug 9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert >> write:fatal:protocol version >> | Aug 9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error >> ` >> >> Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone >> to connect successfully. > Any idea if this actually works with newer android phones? It works with Android 6.0 on my tablet and with 7.1.1 on my newer phone. > Could someone report this to Google? I consider everything broken by > this a security issue and hope that Google will fix it in all releases > they still support. Given the track record of vendors of Android-based phones on shipping *any* updates Google provides, I'd say the chance of those fixes actually reaching the end-user are slim to none. (My Samsung tablet for example got *two* updates in its whole 4 year life span: one to 5.1 and one to 6.0. Monthy security fixes: none.) Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: OpenSSL disables TLS 1.0 and 1.1
Marco d'Itri wrote: > On Aug 11, Marco d'Itri wrote: >> but I see on your link that Android pre-5.x still has a ~25% market >> share, so unless it will drop a lot in the next year I do not think >> that we can cut them off from Debian-based web servers. > OTOH if the PCI council says that TLS < 1.2 has to go by june 2018 > then this will probably not be such a big deal: > https://www.fastly.com/blog/phase-two-our-tls-10-and-11-deprecation-plan/ > But as it has been noted there is more than HTTP, so totally removing > support for 1.0/1.1 may still not be appropriate. Not everything is regulated by the PCI council. If, after upgrading to Buster, suddenly 25% of the students of my university can no longer connect to the wireless network, it will be hell on earth for me and my support staff. It is nice to say "well, then get the other side to upgrade to a new device", but as it has already been said in this discussion: The real world does not work that way. Unless it has been proven that TLS1.0 and TLS1.1 are as broken as SSL3, please keep the support for them enabled in OpenSSL, and just change the defaults in the application to only use TLS1.2 (unless changed by the administrator). Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: OpenSSL disables TLS 1.0 and 1.1
Marco d'Itri wrote: > On Aug 09, Sven Hartge wrote: >> Looking at https://developer.android.com/about/dashboards/index.html >> there is still a marketshare of ~25% of smartphones based on Android >> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the >> moment) block ~40% of Android smartphones from connecting to any WLAN >> using PEAP or TTLS. > Android 5.x should support TLS 1.2: > http://caniuse.com/#search=TLS The Browser, yes. But not the components doing the WPA stuff: , | Aug 9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: TLS Alert write:fatal:protocol version): [owehxperia] (from client ap01 port 54 cli 30-39-26-xx-xx-xx) | Aug 9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert write:fatal:protocol version | Aug 9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error ` Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone to connect successfully. > but I see on your link that Android pre-5.x still has a ~25% market > share, so unless it will drop a lot in the next year I do not think that > we can cut them off from Debian-based web servers. It is far more than 25%. Lollipop, Kitkat and Jelly Bean add up to ~52% of marketshare and I don't think this number will drop significantly below 25% in the next 2 to 3 years. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: OpenSSL disables TLS 1.0 and 1.1
Marco d'Itri wrote: > On Aug 07, Joerg Jaspert wrote: >> Thats nice for any environment where on can freely define that >> everything works like this. >> >> Unfortunately real world doesnt work like it. > Can you describe some examples of what still requires 1.0/1.1 on a > client or a server? I just found out that because of that change my older Android 5.1 based smartphone can no longer connect to my WPA-Enterprise WLAN. Looking at https://developer.android.com/about/dashboards/index.html there is still a marketshare of ~25% of smartphones based on Android 5.0 and 5.1 and 16% based on 4.4. So this change would (at the moment) block ~40% of Android smartphones from connecting to any WLAN using PEAP or TTLS. And when I look at other wireless-enabled things, the ratio for support for TLS1.2-only might be even worse and less quick to change. Grüße, Sven. -- Sigmentation fault. Core dumped.
Is missing SysV-init support a bug?
Hi all! I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which has as a change * [917beed] conntrackd: get rid of the sysvinit support and I wondered, if this is a bug (and at what severity) or not. While I run all my personal computers on systemd (on Sid) and nearly all servers at work have been switched to systemd during the Wheezy->Jessie upgrade, there will still be people left running the classic SysV-Init and as far as I know it has not been deprecated/removed for Stretch. So leaving them out in the cold like this seems wrong to me. To be fair, conntrackd _is_ a highly Linux-centric package, so catering for Hurd or FreeBSD does not apply here, but still ... Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: wiki about block alignment issues
Daniel Pocock wrote: > I've started a wiki about block alignment issues: > https://wiki.debian.org/DiskBlockAlignment > Can anybody comment on specific packages / tools that may help people > investigate or update their systems, maybe adding links to the wiki? There is also an interesting "wrinkle" in the way the Debian installer lays out logical partitions in an extended partition. The extended partition will be _not_ aligned but offset, so that the logical partition (which contains the file system) is then correctly aligned. You have to keep that in mind, when looking at such a partition table with fdisk and calculating the alignment for the partitions. The extended one being unaligned is without consequences, because it does not directly contain the data but is just a mere container for the logical partition, which is correctly aligned. Example: Device Boot Start End Blocks Id System /dev/sda1 *20484010598320051968 83 Linux /dev/sda24010803041940991 9164815 Extended /dev/sda54010803241940991 916480 82 Linux swap / Solaris sda2 -> 40108030/4096 -> 9791.99951171875 -> offset by 2 sectors to the front sda5 -> 40108032/4096 -> 9792 (aligned correctly) Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: suggestion to add package vlan to default instalation DVD
Pascal Giard wrote: > On Wed, Sep 16, 2015 at 3:10 PM, Sven Hartge wrote: >> Josef Masek wrote: >>> it is possible to add package "vlan" to the DVD instalation images? >>> It is tiny package (36kB) and in some special environment (without >>> Internet with DVD in vmware environmen) i have to download and >>> install it manually. >> >> Why? The vlan package is not needed since at least Wheezy to >> configure VLANs on devices since the program "ip" can do everything >> the same or even better. >> >> Also ifupdown was changed to be able to configure VLANs using "ip" >> directly without the need for the "vconfig" from the vlan package. > Pretty sure he meant VLC there. I don't think so, since vlc is nowhere near 36KB in size (it is 1.5MB) while the package vlan is exactly that: Package: vlan Version: 1.9-3.2 Filename: pool/main/v/vlan/vlan_1.9-3.2_amd64.deb Size: 36542 Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: suggestion to add package vlan to default instalation DVD
Josef Masek wrote: > it is possible to add package "vlan" to the DVD instalation images? > It is tiny package (36kB) and in some special environment (without > Internet with DVD in vmware environmen) i have to download and install > it manually. Why? The vlan package is not needed since at least Wheezy to configure VLANs on devices since the program "ip" can do everything the same or even better. Also ifupdown was changed to be able to configure VLANs using "ip" directly without the need for the "vconfig" from the vlan package. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: SSDs have extra "unused" space???
Holger Levsen wrote: > On Montag, 20. Januar 2014, Kevin Chadwick wrote: >> As long as it is a modern SSD (years) or one of the old ones one with >> a sandforce controller (OpenBSD dev let me know about that) then it >> has a good 20% extra space above it's listed gigabytes reserved >> unusable for wear levelling meaning this is a non issue even when >> full? > wait, what? Do you have any vendor statements to support this 20% > extra space? Have a look at this article from Anandtech.com: http://www.anandtech.com/show/6489/playing-with-op , | The [Intel SSD DC] S3700 has 264GiB of NAND on-board but only exposes 186GiB | of it (200GB advertised capacity) as user accessible storage, the rest is | used as spare area to improve performance, consistency and endurance. ` There are numbers for other SSDs in that article. Grüße, Sven. -- Sigmentation fault. Core dumped. -- 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/hacmbhgmm...@mids.svenhartge.de
