Re: OT: Possible memory leak in an exercise of a C handbook
18 Dec 2024 05:03:12 to...@tuxteam.de: > I'm all for concise code, but I usually revert some things in a second > pass when they seem to hurt clarity. After all, you write your code for > other people to read it. As you wrote the code then uness that second pass is weeks or months later then clarity likely still suffers This is why Ada is so fantastic. Adas main requirements included being optimised for reading and maintenance to reduce the D.O.D.s software costs.
Re: X server blocked by SecureBoot
30 Oct 2024 16:25:58 Christian : > I choosed Nvidia again deliberately because I want to play with Tesorflow, > Scikit-Learn and GPT. Or perhaps game. People seem to forget that 20 years ago Nvidia was the only supporter of full featured gpu drivers on Linux. Have you tried disabling secure boot? Unfortunate situation but you would get hibernate too. Otherwise you could see if this is applicable to Debian. https://docs.fedoraproject.org/en-US/quick-docs/mok-enrollment/?ref=news.itsfoss.com
Re: X server blocked by SecureBoot
29 Oct 2024 17:38:39 Timothy M Butterworth : > NVIDIA is a major pain in the ass with Linux. Which is why I do not > use them. Actually this is more Linux being a major pain in the ass to Nvidia. When secure boot is enabled lockdown is automatically enabled. Really debian should provide an Nvidia package that explains the issue, sets lockdown none and runs update-grub. Unfortunately I don't believe the kernel allows just enabling raw io to even signed modules. You can look up some things like disabling debugfs to restore some of lockdowns security. I think kernel memory access is kept disabled.
Hibernate works with secure boot on OpenSUSE
Apparently hibernate works on OpenSuse with secure boot enabled when swap is within an encrypted drive or encrypted itself. Is that true? If it is then why hasn't Debian followed suit?
Lockdown and hibernate
It seems it isn't possible to enable secure boot and disable lockdown any more more with sysrq alt x. In any case. Can anyone save me the time (having already done it?) to come up with a grub cmdline to restore as much of the kernel lockdown as possible e.g. debugfs=off, signed modules, disable kexec whilst keeping hibernate working (I understand the security reasoning). Thank you
Is bundled flash with chrome secure?
So I noticed the vivaldi thread said the latest flash version is 20.0.0.228 which is bundled with chrome and downloaded by the pepper downloader packages. I have had 267 appear in the home folder though but it cannot run. Since the time adobe dropped support, I only have had flash enabled on my myth tv box in google-chrome in /opt. I have home noexec and don't care for any comments as to WHY!!! and actually suggest script interpreters should respect noexec like the grsecurity patch enables!! Though I admit it can be handy to run a quick script and noexec still offers protection against non targetted attacks. What I would simply like to know (when I last checked google were keeping it secure) is whether the bundled 20.0.0.228 is secure. My hunch is currently not. Is an update due shortly and so I have just hit an insecure window? does it download a new version (267) to /home and can that location be changed can I check it's signature or does the browser do so at runtime, so I needn't check it and just copy it to /opt It always seems flash finds a way to be insecure... ahem out of date (it's always insecure) on all systems, I thought linux was different but maybe not? Thanks for any insights -- KISSIS - Keep It Simple So It's Securable
Re: avahi-daemon: Is it *really* needed?
> Yeah, and the best and most correct way to do that is to use the > aforementioned: > > update-rc.d avahi-daemon disable > > avahi no longer uses a ENABLE flag in /etc/default/avahi-daemon. Those > flags are a hack and the above menthod is much better. Personally I disagree in that I believe it should be straight forward and not be time consuming to edit a systems configuration whilst it is switched off (etc on another system). Even moreso an annoyance for me with gconftool/gsettings compared to .fvwmrc etc.. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171737.77215...@smtp141.mail.ir2.yahoo.com
Re: Gain owner of a file using vim :w!
> I'm not sure how this works. What were the permissions on the file before you > edited it? Yeah, you sure your not accessing an sftp with suid dir permissions. I get permission denied. Also setting chattr +ias on a file as root prevents the folder shenanigans On OpenBSD setting chflags schg means you would need to reboot or defeat the very secure kernel. I understand how the folder thing could trick you and I would guess whether it is a bug has been debated many times coming down to inodes vs logic but as for read-only and IPR how could you expect any different, you can prevent others except root reading with standard chmod? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/305833.61127...@smtp101.mail.ir2.yahoo.com
Re: Debian in the sunshine? transreflective screen?
> Anyone have any user experience with transreflective screens? Yep they are brill and don't require a backlight and so sunlight will actually allow you to see the screen perfectly with less power. Unfortunately they are expensive in comparison though nokia used them there isn't a single phone with them these days and so the quest continues for screens that burn our eyes. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/890080.87672...@smtp107.mail.ir2.yahoo.com
Re: touch /var/lib/sudo/$USER / use sudo when unlocking xscreensaver (xfce)
> > > > Not quite. I want sudo 'activated' when I enter my password. > > > > Ie, when I log in to XFCE, or when I unlock the xscreensaver, I have > > in both cases just entered my password. So because I just entered my > > password, I expect sudo to be 'activated'. > > Ah, now I get it. :) > > I suppose there's a way to do this using xscreensaver-command -watch > and some scripting, but if you have only a couple of scripts that > need to run rather often (and are not very "dangerous", i.e. allow no > interactivity or shell commands), then I'd still use NOPASSWD for those > specific scripts in sudoers. > > After all, it's not like you can only have one line in sudoers per > user/group. :) Yeah, usually for guis you want to only run a single command, perhaps so you can get rid of that polkit that should only be doing a single job well. Defaults:user timestamp_timeout=0 -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/174312.34365...@smtp108.mail.ird.yahoo.com
Re: /dev/random vs /dev/urandom
> Hi folks! > > I need create a block file, later use it like archive (with dm). > > What is better use? > > /dev/random or /dev/urandom? > > thanks! > > Pol > You might want to install haveged. You can use that directly without affecting your system entropy. > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org Archive: > http://lists.debian.org/517421c9.1040...@fuckaround.org > -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130421205142.41dfa...@kc-sys.chadwicks.me.uk
Re: Dist-upgrade or upgrade. Which?
> > I always use dist-upgrade but there's not a lot a choose. Upgrade > > upgrades installed packages while dist-upgrade can make more > > significant changes. Once Wheezy becomes stable the two should do > > the same thing. However, I prefer to stay in the habit of using > > dist-upgrade (or full-upgrade for aptitude). > > The point is, you are *SAFER* using upgrade. Using dist-upgrade can > remove half your sysytem before you can say OMG! > > I recommend that new users follow Jochen's advice. This might only apply to Ubuntu but I am sure I have had packages such as kernels with security related updates that needed dist-upgrade to install. So perhaps safer isn't quite the right word. I usually use dist-upgrade and I wonder if using upgrade will allow me to install updates without pulling in jockey and so polkit for steam-launcher. Of course it is no fix but will allow me to stay secure and ignore the problem for now until I do need a dist-upgrade or use equiv. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130421184143.3fe98...@kc-sys.chadwicks.me.uk
Re: rootfs
> > - With a package manager, if any of the rootfs, /usr or /var are > > damaged, you need to either restore the entire set from a backup > > or reinstall. This comes back to the fact that all locations > > under the control of the package manager are a unified whole: if one > > part breaks, the whole thing breaks; more partitions may introduce > > more failure points. > > Not really, there is nothing stopping you from fixing just what is > broken. It may also be that restoring takes longer or you may restore just root. You may choose to fsck -y /usr and do an installed package md5 check in the background with little downtime. Alternative for root you may do an fsck and check all the errors and inodes and restore fix or ignore as appropriate for the more important files. In any case a separation of important files must surely be a good practice that I would prefer to see kept. I can see very little good coming from amalgamation. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130421013621.3846d...@kc-sys.chadwicks.me.uk
Re: rootfs
> On Sat, Apr 20, 2013 at 09:43:08PM +0100, Kevin Chadwick wrote: > > > I am, as a matter of fact, subscribed to the FHS list. If you > > > read the specification, you'll see that it does not in any way > > > require /usr to be a *mountpoint*; it can be located on the root > > > filesystem without any problems. It's actually the default > > > partitioning method. > > > > > > > > Do you have any concrete reasons to have /usr separate from / ? > > > > You need to look at the rootfs section, having them separate makes > > what should be the most critical filesystem (rootfs) 100s! of times > > larger and that quite rightly contradicts the spec (good reasons > > are mentioned but some more benefits of this practice could be > > included however). > > The problem with the FHS here is that it's outdated with respect to > current hardware, the implication of package management, and current > admin practices, and is quite frankly wrong in some aspects. Taking > each one in turn: > > • "The contents of the root filesystem must be adequate to boot, > restore, recover, and/or repair the system." > > No problems with this. However, having /usr on the rootfs does not > interfere with this in any way. > > • "To boot a system, enough must be present on the root partition to > mount other filesystems. This includes utilities, configuration, boot > loader information, and other essential start-up data. /usr, /opt, > and /var are designed such that they may be located on other > partitions or filesystems." > > The keyword here is "may". /usr may be located on another > filesystem, but there is not a strict requirement for that. There's > no "should" or "must" here. Note that other distributions have > removed the possibility for a separate /usr *entirely*. I'm not > suggesting we should go that far; but a separate /usr is pointless > with a package managed distribution. The creation of modern package > managers rendered a separate /usr pointless right back in the mid > '90s, but it's perhaps only in the last few years that we've > collectively begun to fully appreciate the implications. > But it is better to be able to. > • "To enable recovery and/or repair of a system, those utilities > needed by an experienced maintainer to diagnose and reconstruct a > damaged system must be present on the root filesystem." > "To restore a system, those utilities needed to restore from system > backups (on floppy, tape, etc.) must be present on the root > filesystem." > > This is also fine; but having /usr on it does not affect this at > all. However this is affected by the rootfs reliability (below) where I disagree with you. > > • "The primary concern used to balance these considerations, which > favor placing many things on the root filesystem, is the goal of > keeping root as small as reasonably possible. For several reasons, it > is desirable to keep the root filesystem small:" > >"It is occasionally mounted from very small media." > >What does "small" mean nowadays? We are no longer booting rescue >systems from floppy discs. We are using ISO images on CDs/DVDs, >USB pendrives, rescue partitions etc. Realistically, these all > have a capacity of half a gigabyte or more--more than plenty for an > entire system. We no longer have serious size limitations--all these >methods involve the use of media whose size is much greater that > the maximum HDD size when the FHS was first conceived! > Why make an assumption that limits the system. Will this change be applied to debian embedded. > • "The root filesystem contains many system-specific configuration > files. Possible examples include a kernel that is specific to the > system, a specific hostname, etc. This means that the root filesystem > isn't always shareable between networked systems. Keeping it small on > servers in networked systems minimizes the amount of lost space for > areas of unshareable files. It also allows workstations with smaller > local hard drives." > > This part is, frankly, complete bollocks. /usr is not, and *has > never been* shareable at all, in reality. It's technically possible > of course, but this is to ignore the consequence of a modern package > manager. That is to say, you /could/ do it, but it would be > unremittingly stupid. > With a package manager, all filesystem locations under the control > of the package manager are a *unified whole*. They are *managed*. > By the package manager. It's not poss
Re: administration of initscripts
> On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote: > > And that's a Linux problem where some BSDs put lots of effort into > > compliance only to have the standard changed to suit linux due to > > pressure. > > Which standard, POSIX? http://www.itwire.com/business-it-news/open-source/57589-upstream-vendors-can-harm-small-projects-openbsd-dev/57589-upstream-vendors-can-harm-small-projects-openbsd-dev?start=1 > > > POSIX is a very good thing. Do you disagree? I could perhaps > > understand if there were major benefits. > > It's a good thing for helping to write software portable across UNIX > implementations, when that's your goal. It isn't always your goal. > It's slightly less useful if you are only targetting Linux (where LSB > is a bit more useful, but still flawed). It's also quite old, a lot > has happened since 2008. > > > That's irrelevent as a systemd only linux world (which granted will > > never happen despite lennarts best efforts) would make using Linux > > more difficult for many major products where POSIX is a requirement > > and would damage Linux too as cross polination would be less likely. > > Let's explore this scenario in a bit more detail. When is POSIX > mandated? Usually for user-land software written under contract to > government or military, right? In that situation the company is > delivering a product to run on top of an OS. That would not preclude > that OS (which the customer has already got) from using systemd, nor > Linux (with it's non-POSIX-compliant features) nor *BSD (with their > non-POSIX-compliant features)… In other words I cannot see a scenario > where this is actually the case. > That's a very narrow view of what may be delivered. > Does this happen? Or is POSIX compliance only mandated for operating > systems that are deployed/sold to public or military funded projects. > In which case what is important is that POSIX is implemented, not > that it is exclusively implemented — i.e., a *superset* of POSIX > functionality is acceptable. And lucky it is, because all the BSDs > implement non-POSIX functionality, not just Linux. (Although none of > free/net/openBSD are actually fully POSIX compliant anyway: see below) > > > Absolute rubbish and SysV is just one of many methods that correctly > > use an init which also differes between systems but can be POSIC > > compliant. > > I'd like to see an answer to the question another poster put to you > regarding this: which part of the POSIX specification specifically > relates to init systems? > That's a loaded disengenuous question. A system running systemd can not be POSIX compliant ever. How can it not be relevant as pid1, if programs come to depend on systemd then you would have to fork more and more code and not necessarily just for embedded systems wanting leaner code but possibly for POSIX compliance. The key point is Linux running systemd is losing things and gaining almost nothing. > > So launchd is better than systemd because in this regard because it > > is POSIX compliant. > > Do you mean it does not rely on any non-POSIX features? "POSIX > compliant" usually means something else. See e.g. > <http://en.wikipedia.org/wiki/POSIX#Compliant_via_compatibility_feature>, > which lists operating systems which are "Mostly POSIX compliant". > Note: Linux is "mostly", not "fully". Note also, FreeBSD, NetBSD and > OpenBSD are "mostly", not "fully". > I was pointing out that you were twisting things. launchd being POSIX compliant has no bearing on the discussion. Your point was pointless. > > Lennart hasn't got a clue about UNIX. Why not take a true Unix > > source such Brian Kernighan and read "The Practice of Programming" > > and then reconsider. > > If you were a faithful follower of Kernighan UNIX philosophy, you > wouldn't touch those nasty BSDs with a bargepole. Rubbish > What we know of as "UNIX" today is rather an amalgamation of the two > — rather different — east and west coast philosophies. > The book talks about the east and west as you call them not as one being better but both being so depending on the task at hand because the world isn't black and white. What I was saying was that systemd goes against some of the good principles set forward in that book. > > Technical arguments such as you can get from the book I have > > mentioned are very important but pass most people by. > > It's a great book but it's not to be taken as gospel, and it was > written over 14 years ago. More relevant IMHO, but just as much not a > panacea, would be &qu
Re: what's your Debian uptime?
> > > > OpenBSD has only had something like two holes in over a decade > > which is nice for uptime. > > Let's not get carried away here. I was under the impression that > openbsd was one of the best things since sliced bread ... then I read > this: > http://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/ This article is wrong in many ways including saying it includes many of the features of grsecurity. They are actually quite different and saying OpenBSD implemented them after is simply untrue. You can lookup the author of grsecurity making this allegation on the OpenBSD lists if you wish. Saying systrace is recommended to protect from a succesful attack is also wrong. You have to such as with MACs know about things like syscalls and it is actually suggested you don't rely on it at all. Though systrace usage has been added to OpenSSH when run on OpenBSD recently. Not as a reliance but as an extra security measure against DOS attacks and chroot and dropping priviledges is used far more on OpenBD by default (possibly without users even knowing) than on Linux such as in the in base Apache, nginx, unbound, nsd, all of which are audited. Depending on MACS to protect from a succesful attack is bad security practice. The fact that admins time is better spent on preventing successful attacks in the first place and increased complexity of protections it brings is the reason OpenBSD advocates against MACs. Opening quote "OpenBSD was not designed with security in mind and provides no real way to lock down and limit a system above standard UNIX permissions, which are insufficient." It's kernel was and is designed with security in mind (as far as the generic hardware will allow). Linux is not. Only standard unix permissions is actually incorrect which he later leads onto. I shall let you decide what that means about this article. File immutabilitiy is a useful feature which Linux hasn't got in such a useful form and at the end of the day everything comes down to the kernel and it's memory protection. He doesn't seem to understand that programs can use protected memory and that memory and processes are better protected due to kernel design and randomness throughout. OpenBSD has securelevels and with the kernel being far more secure than Linux they are far more reliable than MACs. Without grsecurity. Linux doesn't even allow users to close off the gaping hole of rawio (linux) or video aperture (OpenBSD). Standard unix permissions are extremely powerful and I challenge you to come up with a situation where they are not especially when secondary groups are used. It is certainly clear however that many do not understand the power of unix permissions, especially Redhat. On top of this new technologies like PAM do not have the best security track record. It is worth noting that even if you have the time for SELinux it has had it's flaws (I actually prefer grsecurities RBAC). It is clear that the author even does not understand this. "the user has complete ownership over their files and processes, and the ability to change permissions at their discretion. This leads to many security concerns, and is the reason most attacks can be successful at all" That is not true but is likely over the files they create which can be cotrolled under a DAC system just like a MAC which also has to understand what the user is expected to be doing beforehand. "the malicious process or user will inherit the access of the browser or process that was attacked. The prevalence of the DAC architecture throughout most operating systems is still the primary cause of many security issues today. With many server processes still running as a privileged user this is a large concern." It's actually simpler better and more secure to drop priviledges and work on design. This can often be done by users and is often added to ports on OpenBSD. All then benefit and not just RBAC users. "As an example of what is possible with extended access controls, it a web server process running as root could be set to only have append access(as opposed to general write access available in a DAC system) to specific files in a specific directory, and to only have read access to specific files in a specific directory. If some files need to execute, then that file itself (or the interpreter if a script) can be restricted in a similar way. This alone would prevent web site defacement and arbitrary code execution in a great many cases." __
Re: rootfs
> I am, as a matter of fact, subscribed to the FHS list. If you read > the specification, you'll see that it does not in any way require > /usr to be a *mountpoint*; it can be located on the root filesystem > without any problems. It's actually the default partitioning method. > > Do you have any concrete reasons to have /usr separate from / ? You need to look at the rootfs section, having them separate makes what should be the most critical filesystem (rootfs) 100s! of times larger and that quite rightly contradicts the spec (good reasons are mentioned but some more benefits of this practice could be included however). -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/350028.8692...@smtp105.mail.ird.yahoo.com
Re: rootfs
> > Don't believe opinion as fact just because it's on a server hosted > > by freedesktop.org. Rusty Russel and the FHS is a more > > authoritative (and correct) source, I suggest you read it. > > I never split up / and /usr for the last century or so and they are > all working fine. Wow, your 100 years old and you haven't understood the FHS yet ;-) Working is not best practice. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420010759.4fd33...@kc-sys.chadwicks.me.uk
Re: connect directly to another computer bypassing firewalls using a third server
> That looks like you have to somehow be logged into both hosts and run > nat-traverse on each. But it looks interesting. Firewalls can track and block UDP (create state) even if it is a stateless protocol too, so you may have to have control of the gateways too. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419230357.556ad...@kc-sys.chadwicks.me.uk
Re: rootfs
> > Hi, > > > > I have a debian wheezy server up, I would like to free some space > > on rootfs but can't guess how... > > Here follows the filesystem, any hints? > > > > regrds > > /r > > > > debian:~# df -h > > File system Dim. Usati Dispon. Uso% Montato su > > rootfs 322M 213M 93M 70% / > > /dev/mapper/debian-usr 4,6G 1,2G3,2G 28% /usr > > There's no real need to have /usr separate from / > If you did, you would have gigabytes of free space to play with. > > You could potentially merge the two. Unless you follow the installer, best practice and the Filesystem Hiearchical Standard then no not at all. Don't believe opinion as fact just because it's on a server hosted by freedesktop.org. Rusty Russel and the FHS is a more authoritative (and correct) source, I suggest you read it. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419200924.417ae...@kc-sys.chadwicks.me.uk
Re: rootfs
> I haven't actually looked at your layout but copy something like /opt > to /usr (where it should be anyway in my opinion) and bind mount it. Sorry move it! -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502087.43169...@smtp176.mail.ir2.yahoo.com
Re: rootfs
> >> Ok, here follows the "relevant" ouput. > >> Apart from spf13 vim environment, that I can remove for root user, I guess > >> my only choice would be a pruned custom kernel... am I wrong? > >> > > > > You seem to be using lvm. Can't you shrink another partition to grow root? > > > Yes I could... but I have never managed lvm and this is a production > server.. I haven't actually looked at your layout but copy something like /opt to /usr (where it should be anyway in my opinion) and bind mount it. I did that when the pinned firefox broke to make space for Google Chrome. I've got to get around to getting firefox back it's much more easily configurable and much better than chrome especially in js management with noscript. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/366797.53392...@smtp206.mail.ir2.yahoo.com
Re: what's your Debian uptime?
> The security related flaws are typically in > subsystems that are not part of a minimalist kernel. A reboot is an attackers best friend and potentially an attackers enemy too. However whilst your practice is right. I hope you are reviewing all bugs as the kernel devs simply label them as bugs which should be fixed occasionally with hints and often only external eyes like debian ones label them as security bugs some what later too and as I have said if you really wanted to be thorough you would also need to review the commits to code areas you deploy as Linus himself has stated they can't keep up but you may be able to on a minimalist kernel. Perhaps a minimalist/server kernel project starting base rather than LTS might be an idea if it doesn't exist already. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/907020.49342...@smtp128.mail.ir2.yahoo.com
Re: what's your Debian uptime?
> > > > If i am not mistaken, The OpenBSD Team recommends a clean installation > > every 6 > > month. > > For users following -stable instead of -current, the support goes back two > releases which means about 12 to 18 months, since the releases have been > every 6 months: > > http://www.openbsd.org/faq/faq5.html#Flavors > > So that would tend to limit the uptime. > > Regards, > /Lars Yes and No. Supported (help you in case of problems) certainly as the man power simply isn't there to back port and all the devs run current. However things such as firewalls is no problem and even advocated and you can also compile packages very easily (certainly server packages). The kernel is sound so no reboots. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/676261.45729...@smtp156.mail.ir2.yahoo.com
Re: what's your Debian uptime?
> On the humor side though I rememeber a story about a guy who moved his > apartment. His machine was on a UPS. He determined a way to borrow a > second UPS and daisy chain them for more uptime and then drove like a > madman halfway to his new place where he had previously scouted and > found a public power outlet. He stopped and charged both UPSes up > again. Well I wouldn't go that far but I have taken the insert of a matchbox cut a slot in it and stuck it over the power button so that when reaching round the back there is no way of holding it down by accident. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/183047.41348...@smtp129.mail.ird.yahoo.com
Re: what's your Debian uptime?
> > OpenBSD has only had something like two holes in over a decade which is > > nice for uptime. > > Two holes in the default install, which is a very different thing to two > holes in the entire distribution. It is but you can see the erratas for the whole base system at openbsd.org/errata.html and they are few. There will of course be many unfound bugs but anything included in base receives a good audit before inclusion and some parts a constant one. The default install obviously includes the kernel so I think two exploits in over a decade, one of which was in the over engineered shall we say ipv6 that I have disabled (good practice on OpenBSD too) is very impressive especially when Linus states that there are so many updates every day that bugs are certainly getting in every day. Of course there are benefits to that but it's not security. If I ever run a Linux server for some certain functionality I will certainly apply the grsecurity patch. OpenBSD and linux with the grsec patch have security features that FreeBSD doesn't, even more so on older hardware. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/686045.32367...@smtp143.mail.ird.yahoo.com
Re: administration of initscripts
> On 04/16/2013 03:02 PM, Kevin Chadwick wrote: > >>> Lets not pollute this useful thread with systemd > >> It seems a thread about init systems and administration/tweaking of them > >> is the > >> most appropriate place for systemd to be mentioned. Not least that it can > >> solve > >> the problem the OP had. It should not be ignored or avoided from being > >> mentioned just because some people hate it. Some people hate sysvinit. > >> What we > >> should not do is 'pollute' the thread with any misinformed bias or non > >> objective statements about the suitability of something for a particular > >> job. > >> Let's stick to facts. > >> > > Fair enough. I would always agree with that. I will say I am not biased > > in any way by my usage of BSD. > > > >>> but I will say it would be the absolute last on my list and actually > >>> systemd > >>> itself is incomptible with BSD not just udev and from my experience would > >>> be > >>> laughed out of the room by BSD devs even if it was POSIX compliant. > >> Luckily we're on a Debian mailing list, then, isn't it, and not a BSD one! > >> > >>>> Systemd has "assimilated" udev, in a manner of speaking. Udev can still > >>>> run completely without systemd, but for system builders they have to > >>>> take a lot of extra steps to seperate udev from systemd and install it. > >>>> Worse, some devs of systemd want to fully integrate udev into systemd > >>>> and make it so you can't use udev without systemd. This is bad for many > >>>> distributions as systemd may not be an option. Debian is an example: > >>>> Debian has a couple pet prijects to be ported to things > >>>> like HURD and BSD, which do not provide kernel features absolutely > >>>> necessary for systemd. Some Gentoo developers have forked udev for this > >>>> reason. > > I was merely replying to a few mails at once noting that the above > > suggests udev is the only non posix part. Systemd is too, such as > > cgroups which if you search for on the OpenBSD list you will see strong > > arguments for them actually being practically pointless. I haven't the > > time to look it up or talk about it here but it shouldn't be hard to > > find. > > > > Please also note that it is not about Linux or BSD either but POSIX. > > Without POSIX Linux negates itself from some major projects and > > turning POSIX into Linux only, negates POSIX. > > > > First off: Linux itself is not fully POSIX compliant, even without > systemd: > http://en.wikipedia.org/wiki/POSIX#POSIX-oriented_operating_systems. So > claiming importance of POSIX to Linux is not entirely correct. While > POSIX is IMPORTANT to Linux, it's never been a design goal of Linux to > full comply with POSIX. The Linux Standard Base is probably more > omportant to Linux distributions. > And that's a Linux problem where some BSDs put lots of effort into compliance only to have the standard changed to suit linux due to pressure. POSIX is a very good thing. Do you disagree? I could perhaps understand if there were major benefits. > Second off, so many people misunderstand the goals and design of the > POSIX standards. The entire set is largely geared for source > compatibility between Unix-like systems. I challenge you to find > anywhere in the POSIX standards that defines anythign about the init > system or system manager. > That's irrelevent as a systemd only linux world (which granted will never happen despite lennarts best efforts) would make using Linux more difficult for many major products where POSIX is a requirement and would damage Linux too as cross polination would be less likely. > Third off: SysV is probably even WORSE for compatibility between > Unix-like systems (And I doubt POSIX would even recommend SysV-like > capabilities.), because while it itself will function in virtually any > half-way POSIX environment: Initscripts themselves, which SysV cannot do > anything without, are entirely platform-specific. For example: Debian > initscripts will not work at ALL on an LFS system, which has its own > initscripts. This effectively makes any advantage of usign SysV for > promoting cross-compatibility null when you still have to use very > platform-specific methods to use it. systemd's design with the unit > files and how it works is to allow upstream developers to do what SysV, > Upstart, and OpenRC certainly would not: A universal way for
Re: administration of initscripts
> > I believe very strongly that it is. universality with Linux supporting > > smaller and smaller Arm chips is part of what I was touching on in the > > paragraph you had a hard time deciphering. This is something BSD is > > having a hard time competing with atleast in my experience of wanting > > to be able to use BSD. > > OP did not mention trying to run all this on a very small ARM system. > And it would have to be a very small ARM system to not be able to handle > systemd (I've got it running on a raspberry pi without any issues). > And did it boot slower than with init scripts and waste valuable memory. Lookup systemd on the buildroot list and you will see. Debian may run on even a cheap toaster one day but systemd would causes issues when that is possible. > *You* may discount using systemd because you want to run init on a tiny > ARM system, but this thread is about the OPs problem, not a general init > rant fest. I discount systemd for many reasons. All I have beeen meaning to say is lets not shout about it and users should look up about systemd before you learn to use it as you may regret it down the line. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/249305.38916...@smtp152.mail.ir2.yahoo.com
Re: administration of initscripts
> Although, I accept there is no real excuse for my rudeness. No worries, I have a thick actually english skin as I hope those I talk to do too. If you think that's rude, you are probably a gent. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/727543.38916...@smtp152.mail.ir2.yahoo.com
Re: what's your Debian uptime?
> > > Linux greer 3.2.6 #1 SMP Mon Feb 20 17:05:10 CST 2012 i686 GNU/Linux > > > > > > 22:35:31 up 412 days, 10:05, 1 user, load average: 1.18, 0.97, 0.44 > > > > So you are over a year behind in installing security updates for the > > kernel. (I know, if your machine doesn't have untrusted users and is > > well removed or disconnected from the internet, then that doesn't really > > matter). > > This must not be so. Look, In my case I used a self compiled kernel, with > very > few modules. And as the only security holes have been in kernel modules, I > did > not compile, I needed not to install a new kernel. Those modules were just > not > existent. KISS-style. It makes things more secure! If you use a minimal config then I could believe that but bear in mind Linus famous words of "a bugs a bug". Having looked for security issues in a timely manner myself and having heard someone being very vocal about a security related too like polkit having had atleast one security bug fixed silently. I would still update. I wondered about ksplice once but I believe security restrictions, perhaps grsecurity prevented it from being used which made sense to me. OpenBSD has only had something like two holes in over a decade which is nice for uptime. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/801742.38916...@smtp152.mail.ir2.yahoo.com
Re: administration of initscripts
> > Yes and do you know it was designed to do just what it does for a good > > reason in 32 kb of code. Hello world is 8kb > > Not relevant to choosing an init system. I believe very strongly that it is. universality with Linux supporting smaller and smaller Arm chips is part of what I was touching on in the paragraph you had a hard time deciphering. This is something BSD is having a hard time competing with atleast in my experience of wanting to be able to use BSD. I also believe using that much processing and memory is fundamentally flawed for a tool which may only be required to start processes, can have functionality bolted on easily and users should have the right to a simple and guaranteed secure and easily auditible init which Lennart would not allow if he had his way. And please don't reply to this with his (not his actually) sandboxing rubbish which a is next to useless and b can be used anyway or the taking code from daemons and generalising it to make safer daemons rubbish. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/500818.16543...@smtp105.mail.ir2.yahoo.com
Re: administration of initscripts
> On Tue, Apr 16, 2013 at 10:33:47AM +0100, Kevin Chadwick wrote: > > I think you miss the point which is those unit files depend on C code > > So do classic init scripts: > > $ file /sbin/init > /sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.6.26, > BuildID[sha1]=0x313c383bcfc5369dd98468b31190be2e9b24df74, stripped > $ dpkg -S /sbin/init > sysvinit: /sbin/init > $ apt-cache show sysvinit | grep -i implemented > Tag: admin::boot, admin::configuring, implemented-in::c, > Yes and do you know it was designed to do just what it does for a good reason in 32 kb of code. Hello world is 8kb > > that is not as easy to follow or as well documented as tools which > > follow the unix philosophy such as grep > > grep works just fine on C code, but it's a rather blunt instrument > and not the smartest way to work on C, that's true. Luckily the Debian > archive is brimming over with tried and tested tools for that purpose > (see e.g. ctags) > I am saying it is easy for anyone to follow edit and lookup a man page and even the c code of grep which isn't as complex as you make out and even reduce the c to what is needed if desired in an embedded grep and with a guarantee that any change can be made by users wherever they like for any task and cross platform, all of which are good things. What systemd offers is actually very little when you consider most of it simply utilises what Unix already offers and it does take away and divides not unites communities such as deep embedded from well very few distros and a tiny minority of the roll your own mobile world. > > and you also don't seem to have read between the lines about the detail of > > "more complex to debug". > > Michael doesn't need to read between any lines, I'm willing to bet he's one of > the most well informed people in this thread RE: systemd. He's actually run > systemd, works on the Debian package and triaged many of the bug reports. > Are you trying to say I haven't ran systemd? This is the kind of rubbish I was trying to avoid. > > In any case systemd has had more attention than it deserves so look > > inthis archive or likely any other archive (Gentoos a good one for > > a balanced view) and lwn.net for the arguments and make your own > > decision. Just don't believe the hype and understand that many pages on > > freedesktop.org aren't official or balanced but abused as if they are. > > What does 'official' mean? > If you look at freedesktop.org you will see it has official freedesktop.org hosted projects. Then there are things like systemd which has lots of completely incorrect information written by one guy. One of the latest to be flaunted around being his systemd myths which misses out all the important arguments and skirts around the ones he actually does try to address. I'm sure he has read LWN, so why he hasn't addressed the arguments or allowed comments I shall let you decide upon. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/78227.49579...@smtp149.mail.ird.yahoo.com
Re: administration of initscripts
> > Lets not pollute this useful thread with systemd > > It seems a thread about init systems and administration/tweaking of them is > the > most appropriate place for systemd to be mentioned. Not least that it can > solve > the problem the OP had. It should not be ignored or avoided from being > mentioned just because some people hate it. Some people hate sysvinit. What we > should not do is 'pollute' the thread with any misinformed bias or non > objective statements about the suitability of something for a particular job. > Let's stick to facts. > Fair enough. I would always agree with that. I will say I am not biased in any way by my usage of BSD. > > but I will say it would be the absolute last on my list and actually systemd > > itself is incomptible with BSD not just udev and from my experience would be > > laughed out of the room by BSD devs even if it was POSIX compliant. > > Luckily we're on a Debian mailing list, then, isn't it, and not a BSD one! >>> Systemd has "assimilated" udev, in a manner of speaking. Udev can still >>> run completely without systemd, but for system builders they have to >>> take a lot of extra steps to seperate udev from systemd and install it. >>> Worse, some devs of systemd want to fully integrate udev into systemd >>> and make it so you can't use udev without systemd. This is bad for many >>> distributions as systemd may not be an option. Debian is an example: >>> Debian has a couple pet prijects to be ported to things >>> like HURD and BSD, which do not provide kernel features absolutely >>> necessary for systemd. Some Gentoo developers have forked udev for this >>> reason. I was merely replying to a few mails at once noting that the above suggests udev is the only non posix part. Systemd is too, such as cgroups which if you search for on the OpenBSD list you will see strong arguments for them actually being practically pointless. I haven't the time to look it up or talk about it here but it shouldn't be hard to find. Please also note that it is not about Linux or BSD either but POSIX. Without POSIX Linux negates itself from some major projects and turning POSIX into Linux only, negates POSIX. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/170115.74572...@smtp131.mail.ird.yahoo.com
Re: administration of initscripts
> > + dropping human readable textfiles in favour of c binary code, which makes > > it > > needless more complex to debug the whole show. > > That's non-sense. systemd unit files are text-files in ini-like format > and much more readable then shell scripts with all their boiler plate. I think you miss the point which is those unit files depend on C code that is not as easy to follow or as well documented as tools which follow the unix philosophy such as grep and you also don't seem to have read between the lines about the detail of "more complex to debug". In any case systemd has had more attention than it deserves so look inthis archive or likely any other archive (Gentoos a good one for a balanced view) and lwn.net for the arguments and make your own decision. Just don't believe the hype and understand that many pages on freedesktop.org aren't official or balanced but abused as if they are. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/642243.77365...@smtp149.mail.ird.yahoo.com
Re: Using unstable for certain packages
On Mon, 15 Apr 2013 10:54:17 +0200 Rene Engelhard wrote: > On Mon, Apr 15, 2013 at 10:47:50AM +0100, Kevin Chadwick wrote: > > > Personally I like the about two-year stable release schedule. It is > > > long enough > > > > I appreciate knowing that our setup will not break due to this but > > also compile and download various packages like libreoffice and > > xfce-4.10. > > > > Now I would not expect libreoffice to be packaged but xfce-4.10 had a > > ?? > I meant that I would not expect libreoffice 4 in stable but xfce-4.10 would seem sane. > $ rmadison libreoffice > libreoffice | 1:3.3.2-2~bpo60+1 | squeeze-backports | source > libreoffice | 1:3.3.3-4~bpo60+1 | squeeze-backports | source, ia64, > kfreebsd-amd64 > libreoffice | 1:3.4.3-3~bpo60+1 | squeeze-backports | source > libreoffice | 1:3.5.4-7~bpo60+1 | squeeze-backports | source, sparc > libreoffice | 1:3.5.4+dfsg-3~bpo60+2 | squeeze-backports | source, amd64, > armel, i386, kfreebsd-i386, mips, mipsel, powerpc, s390 > libreoffice | 1:3.5.4+dfsg-4 | wheezy| source, amd64, > armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, > powerpc, s390, s390x, sparc > libreoffice | 1:3.5.4+dfsg-4 | sid | source, mips, > sparc > libreoffice | 1:3.5.4+dfsg2-1| sid | source, amd64, > armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mipsel, powerpc, > s390, s390x > libreoffice | 1:3.6.5-1 | experimental | source, s390, > s390x > libreoffice | 1:4.0.2~rc1-1 | experimental | source, powerpc > libreoffice | 1:4.0.2~rc2-2 | experimental | source, amd64, > armel, i386, kfreebsd-amd64, kfreebsd-i386 > > And yes, 4.0.x will also be in wheezy-backports when it's time for that. > Using it from "unstable" is bad, because it'll also give you a loads > of libs not in wheezy which might easily end up pullling a new libc6 etc. You can install it very easily as a separately verifiable .deb package (actually many but the wildcards bring it to about 4 commands). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/538982.74008...@smtp129.mail.ir2.yahoo.com
Re: administration of initscripts
>> file-rc "works", but only just. I would not be surprised if it was >> removed for the next stable release--it's simply incompatible with >> dependency-based booting. That's a shame, I would take direct editing of runlevel.conf over dependency-based booting myself. >> When you are using dynamic ordering, file-rc >> is just the same as sysv-rc except you have no parallelisation of >> boot scripts, parallelisation is the last thing that I want with multiple downsides. What's the gain, to save two seconds when I can save 20 by swapping kde for fvwm or xfce and more than 2 seconds by editing the bios. > But I've not come across a need > for altering the default runlevels (or using runlevels other than 1 and > 2) at runtime in over 15 years of using Debian. If there are any > genuinely useful use cases for them, I'd be interested to hear what > they are, since generally most people ignore them entirely. Same here, I setup systems to do a job and a runlevel to fix that job if need be. OpenBSD has just two runlevels and the simplicity and usability of it's rc system is one of my favourite things about it. Lets not pollute this useful thread with systemd but I will say it would be the absolute last on my list and actually systemd itself is incomptible with BSD not just udev and from my experience would be laughed out of the room by BSD devs even if it was POSIX compliant. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/669559.78075...@smtp203.mail.ir2.yahoo.com
Re: administration of initscripts
> > I have been using Debian for many years now. In all of that time I > > have never wanted to "manage" init scripts. I always wonder. What > > are people trying to do? > > Hi Bob, > > For an example of where one will want to "manage" the init scripts, > take a look at the thread in debian-user with subject "Serveur with > encrypted partition : 2 steps boot." started by er...@rail.eu.org . If you are not using a printer, it is also security 101 to disable it's listening service. I quite like OpenRC but am currently looking into file-rc, which I would prefer if direct changes to it were kept but I will have to find the time to work out how to do that without using commands like update-rc.d which are not my preference. I guess I simply prefer the OpenBSD method of an include file that would override runlevel.conf and may have to look into adding that to file-rc or a fork at some point. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/651791.37735...@smtp179.mail.ir2.yahoo.com
Re: Using unstable for certain packages
> Personally I like the about two-year stable release schedule. It is > long enough I appreciate knowing that our setup will not break due to this but also compile and download various packages like libreoffice and xfce-4.10. Now I would not expect libreoffice to be packaged but xfce-4.10 had a year or two year testing cycle before release and so I see it as perhaps one of very few exceptions. OTOH I have just run into a glib(gio) segmentation fault in debian 6 likely due to mime.cache file corruption in .local, certainly due to that file in any case. Quite Ironic that xfce-4.10 is more stable thanan included package which it is built on ;-). Perhaps it was caused by the mix of old and new code but then I suppose that glib bug would have been fixed. In any case, no problem just thought it was worth consideration as a particular case. I am probably going to drop the xfce4-panel from our plans now anyway. Nothing to do with xfce but glib taking everything down including the panel and synaptic for what should be a non issue as it is a file that could just be deleted is simply unacceptable to me when there are rock solid alternatives. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/719268.17399...@smtp150.mail.ir2.yahoo.com
Re: dbus - Was: A thread that shouldn't be mentioned anymore
On Sat, 13 Apr 2013 10:34:36 -0700 Kelly Clowers wrote: > >> DBus isn't a problem per se, it just can cause issues, when implemented > >> without thinking about the needs of all users? > > > > Right but it's actually much worse than that. Take mozilla firefox even > > which may or may not have been changed due to me bringing it up on the > > dev-security list. Without dbus in a chroot it would die, the reason > > was handling it's text configuration files, which is obviously > > rediculously pointless and I assume with some confidence, actually quite > > dumb. > > Are you sure about that? I have never seen anything dbus related in > any version of Mozilla or Firefox, aside from one extension that never > really when anywhere. It does as you can see from the output when running it in a chroot and for atleast one release it would die. (firefox:1515): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Failed to connect to socket /tmp/dbus-jEHTNI62oh: Connection refused Fontconfig error: Cannot load default config file -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2572.57457...@smtp112.mail.ir2.yahoo.com
Re: Using unstable for certain packages
> Then again, if you build from source, you'll lose the automatic upgrade > feature provided by apt/aptitude. > > Anyone, please correct me if I'm wrong. I believe so. There are some debian source building tools and mepis archives are usable perhaps best with pinning. I plan to experiment with the latter but have no experience of it. I pinned experimental debians firefox but it broke after a few updates. I expect mepis repos to actually be more workable as they use the stable base and bild new packages. Incidentally. I do wonder if debian stable should accelerate some packages which follow a more stable dev cycle like xfce-4.10 where it has already been well tested. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/701928.15807...@smtp112.mail.ird.yahoo.com
Re: dbus - Was: A thread that shouldn't be mentioned anymore
> DBus isn't a problem per se, it just can cause issues, when implemented > without thinking about the needs of all users? Right but it's actually much worse than that. Take mozilla firefox even which may or may not have been changed due to me bringing it up on the dev-security list. Without dbus in a chroot it would die, the reason was handling it's text configuration files, which is obviously rediculously pointless and I assume with some confidence, actually quite dumb. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/556735.15807...@smtp112.mail.ird.yahoo.com
Re: MICROSOFT HIRED THESE PEOPLE TO SABOTAGE OPEN SOURCE
> GConf I *think* was merely a GNOME construct, so if you're not a GNOME > user you don't have to bother with it. There wasn't really much of a > technical issue with it except it emulates the Windows Registry in > superficial ways. There are technical issues such as actually more difficult administration despite claims to the opposite (you shouldn't *need* to use new tools which may not even be available where the configuration happens) and whilst xml is an improvement over binaries formats to save processing no one needs to save, it is not the best method. > > 4. First off, nothing in that image has anything to do with what the guy > says. At any rate, not wanting to contribute to open source gaming > hardly puts someone in Microsoft's employ. You assume he was saying he thought it true, perhaps he was being sarcastic in that there are negative comparisons to be made that could lead you to believe it and that incidentally I will add (without alledging anything and acknowledging some of the great work Redhat does) almost always point to the Redhat desktop world, for whatever true reason that has not yet been properly identified. The image has far more value that the way this thread has been hijacked. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/11852.15807...@smtp112.mail.ird.yahoo.com
Re: dbus - Was: A thread that shouldn't be mentioned anymore
> D-Bus is good overall... The good thing about standard IPC was that you would have to develop the protocol etc.. which means if your app used it. 1./ You needed to use it otherwise you wouldn't. 2./ You made an app specific mechanism (very good if your good but could be bad, the latter is what dbus tackles) The problem with dbus isn't dbus, it is that developers are becoming a big problem because they are using it way too much as a first choice. You should only use dbus when you need to. Some software is unfortunately encouraging this and in turn other bad practices. Take Windows, atleast XP (I haven't looked so close since but I expect little has changed in this department), Scripts have to be enabled to activate XP and IPC is required for almost everything. Try switching off RPC (prepare to reboot to re-enable it), and guess what, Windows is completely unreliable and insecure. Polkit instead of sudo, IPC and scripts when neither are required or a good choice. The reason for IPC, because it wasn't designed for just the task that sudo does. Why polkit is used rather than sudo because polkits author helped write the odd script like pm-suspend and is in with the udisks author. What I really don't get though is why there are so many easily avoidable hard dependencies. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130409225956.46ecf...@kc-sys.chadwicks.me.uk
Re: [SOLVED]Re: Squeeze X86 with 4GByte RAM?
> Today I successfully reinstalled my NVIDIA driver and repaired kernels - > and after restart computer it could boot the x86 kernel with Bigmem option. I should have said this earlier too sorry but you will know for next time. When you had your flashing cursor on a blank screen then, there was likely no need to reboot to a recovery shell. You could just use Ctrl, Alt, F1 to switch to the console Install nvidia, if not from repos then perhaps with Nvidia*.run update And start your display manager with /etc/init.d/?dm restart I would warn that doing it like that is convenient but runs the download as root which isn't a brilliant idea but apt does that anyway ;-(, though it is signed as a valid nvidia package with apt atleast. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/740226.66009...@smtp141.mail.ird.yahoo.com
Re: Mozilla Firefox ESR for 64bit systems
> But regarding to updates the management by ports for a FreeBSD noop > like me is a PITA and btw. I also prefer binaries to compiling _really > everything_ from source. Theoretically you can manage FreeBSD by a > package management that does provide binaries too, but when I > installed FreeBSD there were no repositories available, IIRC > regarding to a security issue, I guess there was an attack. OpenBSD does have binary packages and a pretty awesome sndio that beats pulseaudion in many ways, however it support for 24bit hasn't been done and non mainstream drivers would need porting anyhow. We are getting way off topic here and may be abusing this list (even if debian has BSD herd), however I wouldn't mind knowing what high quality sound card you use that is compatible with FreeBSD (if you don't mind letting me know off list) as I have a high quality audio hardware project in the future and a freebsd driver may be quicker to port to OpenBSD, which is always my first choice wherever it's appropriate (again 24bit may or may not be a problem but the design of sndio means the latency could be very good I believe). -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130407181358.24015...@kc-sys.chadwicks.me.uk
Re: Mozilla Firefox ESR for 64bit systems
> > Breaking the system because Arch haven't tested it well enough, or > > released the right information happened atleast three times in the 6 > > months that I used it. > > It only happened one time for me, when they switched from init to > systemd I dropped Arch for perhaps a year. But with Debian and Ubuntu > breaking the system happens several times a year. IMO the testing is > much better for Arch than for any other distro I used. By broken I guess you mean changes stopped your audio setup working?, interesting. What did you do during that year, try Gentoo or debian/ubuntu? I meant for updates. I have never had to manually intervene to enable successful updates with any other package management system including Sabayon's? Base may go out of sync on OpenBSD but that is perfectly predictable and requires perfectly predictable sudo commands. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130407165122.35edd...@kc-sys.chadwicks.me.uk
Re: Mozilla Firefox ESR for 64bit systems
> > I use Firefox not with Debian, > > but other distros. > > I didn't notice that..I see Arch Linux listed among the multitudes: > > http://futurist.se/gldt/wp-content/uploads/12.10/gldt1210.svg > > You can't have too many Linux distros apparently. What's to like > about Arch Linux? > -- I feel compelled to reply. I was looking at Alpine and tried Arch after a user called Landry mentioned on the OpenBSD list that he had really liked Arch as one of the most BSD like distros but didn't like the direction they were heading. I wish I had known about Sabayon then. Arch has some good plus points such as a very fast package manager and package updates being released quickly (though you will still find some corner packages debian knows are vulnerable but hasn't fixed yet perhaps around for longer), but only if you are competent and also don't mind wasting time when they release changes may it be an OK system for you. One of their main principles is to follow upstream to the letter and use that reason to silence users, which is the opposite of Gentoo which tries to empower the user as much as possible and so is compilation based to avoid the dependency issue (unfortunately a big barrier to many and hence my preference for better designed software). Breaking the system because Arch haven't tested it well enough, or released the right information happened atleast three times in the 6 months that I used it. It is actually the most unprofessional distro I have ever come across and I have tried a huge number of various UNIX types. Sabayon based on Gentoo but without the compilation comes as a fully functional KDE desktop even with GUI package management out of the box, unlike arch and has all the plusses of Arch such as bleeding edge packages and without the other drawbacks of Arch. It also has a server version if you wish like Arch to only install what you use (ignoring dependencies) initially. The package manager requires a lot more cpu time but much more complete and your system will never break without support and I haven't seen a breakage requiring admin intervention and unpredictable root commands required yet even with very infrequent updates. It is unsupported but you could if you wish even mix the Gentoo build system which is very powerful (no polkit or no pulseaudio useflags tha apply to all builds) with the binary packages and so work around some dependencies without building everything. On Arch, if you don't update for "they often say two weeks, but this is rubbish" a certain amount of time, they say you can't, of course it actually just gets more difficult. If you Google "Arch" "unprofessional" you will see they do have quite a long history of burying problems apparently including removing forum pages and recently moderating even the users list but allowing devs obviously to make comments that have since been found to be incorrect. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130407151613.05f2c...@kc-sys.chadwicks.me.uk
Re: " google chrome has stopped updating and no longer supports this version of your O.S."
> I'm using Debian Squeeze X86 - 2.6.32-5-686 - and Chrome always show > me this message. > > Why? How to solve this? https://code.google.com/p/chromium/issues/detail?id=224537 Perhaps it will be fixed. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406143548.62a09...@kc-sys.chadwicks.me.uk
Re: " google chrome has stopped updating and no longer supports this version of your O.S."
> you > could install a minimal up-to-date Linux distro to a virtual machine > running on Squeeze If you are short of memory, you don't actually need to waste the memory to run it either, you can quite easily run it from a chroot (you may have to sort dbus out) and assuming the software doesn't require a newer kernel or do silly things with dbus. lsof is handy to shut all the things that have started down after. I've done that before as I had issues getting webm encoding up and running. You should still be able to update it from the chroot too for security reasons, but may have to remember to do so! -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406141334.18761...@kc-sys.chadwicks.me.uk
Re: Will unix ever get out of dependency hell
> > Why on earth does so much of the default desktops depend on polkit > > when very little breaks when it is disabled! > > > > Because "very little" is not "nothing at all." But 99% of the code would work just fine without it and does if you remove it's suid. On Fri, 05 Apr 2013 15:39:30 -0400 Phillip Susi wrote: > > I have decided that sudo is superior to polkit in every way for > > both developers and user except for if developers want to be lazy > > and outsource policy creation to more general and so less specific > > and so obviously likely less secure ones. I do not wish to debate > > that and all debates I have seen have simply shown a lack of > > understanding of what sudo can do. > > One is not "better" than the other as sudo and PolicyKit do two > completely different things. sudo is a command used to run other > commands as root. PolicyKit allows services that ( typically, but not > necessarily ) are already running as root to accept requests to > perform actions via DBUS in a restricted way. If you really wanted to do that you would find the likes of Selinux, RBAC, TOMOYO and apparmor more effective, useful to a user and less of a risk, however they do not save you from writing bad code and sudo encourages the best of that in a nice priviledge seperated utility. If it was the case that polkit just did that then sudo would still be my choice as it is not always running, is filesystem based and as Android realises (we'll ignore their dbus security problems) the program dev is the only one who can truly minimise priviledges (though I wish Android would let you override them, perhaps ubuntu-mobile will) but it wouldn't be a big problem and we wouldn't have all these dependency issues and when reducing the number of root programs such as rsyslogas it's own user, you could decide whether or not to run polkit with no restrictions. Let's analyse the situation due to polkit doing two things and primarily it's secondary task rather than one thing and doing it well as per the unix philosophy. The man page says it does as you have said, though I have seen very little of that, thankfully as it is wrong inmy book) and it also handles policies granting priviledges. Ignoring the positives of sudo and bearing in mind sudo makes no stipulations upon users systems, uses zero resources (reports of Gentoo systems without polkit being quicker) and is easy to configure even from a console, lets look at just the dependency negatives of polkit (this post is already too long) which I am convinced was developed by red hat to fit in with pam and because they seemingly have little idea about sudos abilities and group permissions, unlike debian who always used them fairly well. Let's not forget that pam has not a got a great security record either. nvidia-settings wants to install an xorg.conf file. An Nvidia user could easily have this ability via sudo and a sudoers policy could be provided in two seconds. Maybe a user like me doesn't even care and just wants to create a config and install it himself even or just change the brightness upon login from an rc script. This requires no extra priviledges. What are his choices run polkit with all the defaults which is far more permissions and code running as root than he needs. Look into locking it down, yet it is still pointlessly running as root and notoriously annoying to configure not to mention pointlessly pulling in things like the JS package which aids rop attacks. Disable it's suid and if he knows how, redirect all the setuid not correct logs to null. Or the best option for the average user with any ability at all. Remove polkit. I decided to make my Ubuntu gaming machine leaner for Steam recently and I was appauled how bad the situation needlessly is. The whole of KDE out the window, when 99% of it has nothing to do with polkit, no problem, I was aiming for leaner anyway. Udisks, no problem, having to use usbmount or some udev rules to run the beautifully unix like mount program is a stupid problem to have but again, I can live with it and I do anyway for systems I wish to secure. nvidia-settings gone, how annoying. Install from nvidia.com, still without polkit and I have 100% of it's functionality back. I just have to update it manually. Pulseaudio gone. Ok I can use AlSA, pulseaudio doesn't work witha grsecurity kernel anyway and I can finally get around to learning about jackd which is meant to be far better anyway and perhaps apply it to all my systems. Steam-launcher gone as it requires jockey which requires polkit. Ok I install Steam-launcher from steampowered.com. Runs just fine. I am annoyed but glad with my lean machine. BUT, now even though my machine works fine and how I want, I can't update the machine without pulling in polkit for jockey that the steam launcher that I wasn't allowed to install from the repo requires. These types of problems have spawned things like spacefm that I am very impressed with for it's independe
Will unix ever get out of dependency hell
Why on earth does so much of the default desktops depend on polkit when very little breaks when it is disabled! I think some important principles have been forgotten...or never learnt in the first place in these 'modern' times. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/943499.83243...@smtp186.mail.ir2.yahoo.com
Re: NEWBIE question Re: static or dynamic /dev
> What does it mean when /dev is said to be static? dynamic? > What should I be reading about? On Linux, static tends to be used on embedded systems for speed and sanity when you know about all the hardware that will be connected and don't want anything interfering. OpenBSD has a Makedev script which builds the nodes. With dynamic the device nodes are created as needed rather than being pre-prepared. The fact the filesystem is dynamically sized in ram too is irrelevent really and simply makes it easier to have a read only root filesystem. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/831428.92679...@smtp124.mail.ird.yahoo.com
Re: Squeeze X86 with 4GByte RAM?
> If I run grub with "linux-image-2.6.32-5-686-bigmem (Recovery Mode)" it > starts fine and I have all the 4GByte of RAM - but when I run the same > without Recovery Mode it shows me black screen with blinking cursor and > wait forever. > > I think it was because when I give more memory to the computer also I > change its videocard from NVIDIA 6600 to NVIDIA 9400GT. What should I do > now? How to repair video driver? You probably have a mismatched nvidia kernel module (wrong module for the kernel change) so try reinstalling your nvidia driver. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/178213.92679...@smtp124.mail.ird.yahoo.com
Re: Squeeze X86 with 4GByte RAM?
On Thu, 4 Apr 2013 20:23:25 +0200 Gábor Hársfalvi wrote: > try find options about big memory, PAE in the BIOS -> After > installing RAM at first I saw in BIOS and it looked all of 4096MByte. > So what about BIOS? > > How could I see what is in the kernel - Bigmem and PAE? As I wrote I > installed and tried "Linux 2.6.32 for PCs with 4GB+ RAM" > "linux-image-2.6.32-5-686-bigmem" Package. I too use x86 for the odd non-repo software, however I have a machine with 4Gb of Ram and 3.5Gb shown in bios yet only around 3 Gb usable. I have tried multiple OS and never have the full RAM available. I have put it down to a rather crap BIOS as non of the BIOS options make any difference. p.s. The main case that eats the ram is usually virtualbox. In that case adding sysctl vm.swappiness=0 to rc.local makes a big difference. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404230301.17b23...@kc-sys.chadwicks.me.uk
Re: permissions/sudo/sudoers
On Tue, 2 Apr 2013 12:43:56 -0600 Bob Proulx wrote: > (Use 'visudo -f /etc/sudoers.d/local-foo' explicitly.) But > it makes upgrades easier so I do it this way. What is so difficult about that and sudoers could be for users and sudoers.d for dev changes. You could even only warn upon uncommented entries. Compare kdmrc with lightdm.conf. The mergers really should be cleverer too. It is not difficult to check the part that you are changing has not changed. Which is easier between kdmrc and lightdm.conf before the removal of commented entries and which has the most forum posts asking about examples, it is lightdm.conf. Ok so kdmrc seperating out into a seperate file like sudoers.d would be better with no merging by the system as long as you don't end up with lots of files rather than 2 like file-rc (I prefer) compared to the symlink mess. Or even worse sudo with polkit which expects users to allow default generalities and encourages them to copy and paste as root and use a browser even on servers. I have to say I am surprised there are so many threads saying polkit is superior without justification when it is clearly inferior to sudo and simply duplicates security consideration and gives 20x the auditing work. I did leave one useful tip out too. Default:username timestamp_timeout=0 will make sudo ask for the password for that particular user everytime and I believe can be used on the fly. There is no necessity to use just one user for admin. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402211536.53efd...@kc-sys.chadwicks.me.uk
Re: permissions/sudo/sudoers
On Tue, 2 Apr 2013 01:45:53 +0200 sp113438 wrote: Personally I think it would be great if package devs added perhaps commented by default lines sudoers or to a file in sudoers.d There is no need for groups and logging back in for the average system and sudoers changes take immediate effect whereas group changes don't. Though groups can be handy. Sudo is much easier to use, encourages better programming and is more secure and more powerful than polkit partly due to being filesystem based and certainly less disruptive as it is simply a tool in the proper UNIX sense. You should use visudo as root to edit sudoers as it will warn you if you have mad a mistake before applying the new policy > add to /ets/sudoers: > yourname ALL=(ALL) NOPASSWD:ALL Or to be more secure as you really shouldn't do the above even with Requiretty enabled and even if using a seperate autologged in user from the console yourusernameALL=(ALL) NOPASSWD: /usr/bin/apt-get install [a-zA-Z0-9-]* or to match more packages yourusernameALL=(ALL) NOPASSWD: /usr/bin/apt-get install * Some others may be handy too. yourusernameALL=(ALL) NOPASSWD: /usr/bin/apt-get install [a-zA-Z0-9-]*, /usr/bin/apt-get update, /usr/bin/apt-get dist-upgrade, /usr/bin/aptitude This one should have a password yourusernameALL=(ALL) sudoedit /etc/apt/sources.list Using synaptic to decide what to install (you don't need root to browse) before using aptitude, isn't a bad idea. Later rules override previous ones which may matter if a more inclusive match such as ALL commands allowed with password comes after a NOPASSWD match. Unfortunately apt downloads as root. It is priviledge reduction in things like that that distros should be focussing on rather than wasing time on this polkit when sudo exits, especially because it's predecessor was apparently criticised out of existence. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402112302.458b0...@kc-sys.chadwicks.me.uk
