Re: [gentoo-user] Good/better/best filesystem for large, static video library?
Am 27.12.2012 01:18, schrieb Alan McKinnon: I am *very* impressed with ZFS for this. Yes, I know, it's not really there on Linux - I use it on FreeBSD (FreeNAS). It has everything I've wanted in a filesystem for a long time, and all the crap I've stuffed into my head over many years related to storage just goes away. It doesn't go to some place I don't have to deal with it, it just ceases to exist. Very nice. There is no more weird partitions from the days of DOS, no PV/VG/LV to remember the details of. There is only storage and ZFS knows what I want to happen with each chunk of it. A chunk (my term) in this context is a directory and everything below it. ZFS doesn't have partitions and filesystems. It has volumes. A volume is sort of a cross between a filesystem (you mount it and can assign quotas to it) and a directory (you assign permissions and ownerships to it). You can overcommit storage space and quotas - you do not get disk full errors and three days of nightmares while you figure out how to deal with this. the FS just tells you it used more than the allocated space and keeps telling you till you get it under the limit. mv'ing a few TB of video to a different FS to free up space is not fun at all, but with ZFS it's like an mv on the same FS (that volume thing again). It checksums every write and lets you know if things fail. It has proper snapshots built in - that's proper as in copy-on-write so they don't really take up space until you start modifying files. Your media collection is like mine - I only add to it and seldom delete, so I have months of snapshots that consume about 1% extras space. Dale's rm problem cannot happen to me anymore hehehehe ;-) In summary, it does everything I want and does it well. It can also do other things I don't want but others might (eg de-dupe). I also used ZFS for that kind of storage and it was very pleasant to work with. Performance is an issue if you use zfs-fuse for example, although there are people running zfs-on-linux on LUKS for their main working machine (using an SSD, that helps!): https://mthode.org/ describes such a setup (although slightly off-topic in context of media libraries). I had the pleasure to write a feature about that and provide a demo-vm: http://www.oops.co.at/en/publications/beitrag-fuer-linux-magazin-012013-zfs-und-luks (german feature, sorry ...) - Using snapshots with ZFS really is fun and let's you rethink stuff. It makes doing backups easier and you can send and receive them via pipes (think ssh here). ZFS thinks of storage in the way we think of RAM: plug in some more and everything (as in every filesystem) is able to use it, just a pool of ressources (actually it uses that term all over, a zfs pool called tank). I'd love to use it as root-fs sometimes, but I still hesitate. Might be better to stay with the filesystems most linux-users use, just to benefit of the huge tester-group :-) For media-storage I wouldn't hesitate to run zfs-on-linux on a mirror of 2 disks or so. With that you benefit of the so-called self-healing: If the checksum for block X on disk sda isn't correct, very likely the checksum for block X on disk sdb is still valid. ZFS sees that, creates a new block X on sda, with the correct contentchecksum and drops the corrupted block (and doesn't reuse it, AFAIK). That is a great feature ... maybe not too important for video where the occasional bit error isn't that much of a problem. But good to have for other stuff ... Greets, Stefan
Re: [gentoo-user] IPTABLES syntax change?
Michael Orlitzky mich...@orlitzky.com writes: The 'conntrack' module is supposed to be a superset of 'state', so most things should be compatible. You really have two warnings there; the first is for the state - conntrack switch, and the second is because you're missing the --state flag in your rules. In your example, you turn on the state matching, iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED but you don't specify *which* state(s) you want to match. It wants you to specify --state SOMETHING. I'd guess that it used to interpret no state as any state. The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. The solution is to either change all your rules to use -m conntrack --ctstate XXX before upgrading or editing /var/lib/iptables/rules-save to globally replace '-m state' by '-m conntrack' and '--state' by '--ctstate' prior to the upgrade and (at least temporarily) edit /etc/conf.d/iptables to set SAVE_ON_STOP=no. The same will also need to be done with ip6tables if you use that. I think that this is a serious enough change in behaviour that an elog warning should have been issued.
Re: [gentoo-user] Good/better/best filesystem for large, static video library?
Am 27.12.2012 01:18, schrieb Alan McKinnon: On Tue, 25 Dec 2012 07:41:01 -0800 Mark Knecht markkne...@gmail.com wrote: Hi, Merry Christmas to all. Upgrading an external USB2 drive at home this Christmas morning to 1TB for more video storage space. One large partition, non-raid, files are around 1GB. The drive holds only static video files that get written once and don't change or get erased. No MythTV stuff or anything like that. This disk reside on my main desktop machine and gets backed up every couple of days to another USB2 drive (FAT formatted unfortunately) which attaches to the TV. With the previous local drive I used ext3 and have had no problems. I'm just wondering if there's a better choice why. I am *very* impressed with ZFS for this. Yes, I know, it's not really there on Linux - I use it on FreeBSD (FreeNAS). It has everything I've wanted in a filesystem for a long time, and all the crap I've stuffed into my head over many years related to storage just goes away. It doesn't go to some place I don't have to deal with it, it just ceases to exist. Very nice. There is no more weird partitions from the days of DOS, no PV/VG/LV to remember the details of. There is only storage and ZFS knows what I want to happen with each chunk of it. A chunk (my term) in this context is a directory and everything below it. ZFS doesn't have partitions and filesystems. It has volumes. A volume is sort of a cross between a filesystem (you mount it and can assign quotas to it) and a directory (you assign permissions and ownerships to it). You can overcommit storage space and quotas - you do not get disk full errors and three days of nightmares while you figure out how to deal with this. the FS just tells you it used more than the allocated space and keeps telling you till you get it under the limit. mv'ing a few TB of video to a different FS to free up space is not fun at all, but with ZFS it's like an mv on the same FS (that volume thing again). It checksums every write and lets you know if things fail. It has proper snapshots built in - that's proper as in copy-on-write so they don't really take up space until you start modifying files. Your media collection is like mine - I only add to it and seldom delete, so I have months of snapshots that consume about 1% extras space. Dale's rm problem cannot happen to me anymore hehehehe ;-) In summary, it does everything I want and does it well. It can also do other things I don't want but others might (eg de-dupe). I am a big fan of zfs myself. I use zfsonlinx on my workstation (only /usr/portage and /usr/src atm, but with on-the-fly compression, very nice on my small SSD). Unfortunately the zfs implementation is a few large steps behind zfs on *bsd Migrating my NAS to ZFS is something that has been floating around my head for a longer time. But I am not really sure if I want to switch from gentoo to FreeBSD on my NAS. zfsonlinux is there, but it's first release was early 2011, so it's still pretty young. I guess for the time being I stick to an old credo: never touch a running system
Re: [gentoo-user] Re: 3.7.1 SATA errors -- Bisect done
On Wed, Dec 26, 2012 at 9:14 PM, fe...@crowfix.com wrote: On Wed, Dec 26, 2012 at 08:53:14PM -0800, Mark Knecht wrote: Possibly related? https://bugzilla.kernel.org/show_bug.cgi?id=51881 Indeed :-) The patch author directed me there, I've applied the 51881 patch to the 3.7.1 sources, and it just started compiling. Glad you're finding a solution. Hope it works out. Cheers, Mark
[gentoo-user] Re: problem starting openvpn after recenet upgrade
Joseph wrote: I'm having problem starting openvpn after recent upgrade. When I try to start it I get a normal respond: openvpn.client_clinic_atom start * Starting openvpn.client_clinic_atom ...[ ok ] * WARNING: openvpn.client_clinic_atom has started, but is inactive but ifconfig is not showing this connection in addition it looks strange, not as it used to: ifconfig eth1: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 10.0.0.100 netmask 255.255.255.0 broadcast 10.0.0.255 inet6 fe80::21b:21ff:feb8:27b6 prefixlen 64 scopeid 0x20link ether 00:1b:21:b8:27:b6 txqueuelen 1000 (Ethernet) RX packets 16129 bytes 9087618 (8.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 15573 bytes 2667489 (2.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xfddc-fdde lo: flags=73UP,LOOPBACK,RUNNING mtu 16436 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Local Loopback) RX packets 1218 bytes 1433926 (1.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1218 bytes 1433926 (1.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Known problem. Rebuild openvpn and it works again. The build adds some hard coded paths for some net-tools utilities and the location of ifconfig has changed :-/ - Jörg
Re: [gentoo-user] Re: 3.7.1 SATA errors -- SOLVED
On Wed, Dec 26, 2012 at 09:41:54PM -0800, fe...@crowfix.com wrote: I configured a minimal kernel to test it sooner, and it booted to a prompt. Now I am compiling with my normal config, including encfs and a lot of other gorp, and will try it in the morning. My bloated fully-larded normal config version of the patched 3.7.1 kernel also works. dmesg logs match with the usual differences in USB assignments and a few messages which changed wording. The patch author says the patch is just waiting for the maintainers to approve it up the line. I do not know if that means it will be in 3.7.2. Thanks to everyone who helped here, especially with git bisect. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 2012-12-27 02:14, Canek Peláez Valdés wrote: I really think that's the crux of the matter Pandou: udev/systemd serves to the wants of the many. The eudev fork serves to the wants of systemd+udev serves the large mass (users of mainly Fedora and other distros using systemd) that doesn't care/know computers. a very few which really don't want an initramfs, when it has a lot of technical advantages. It has some problems, of course, but we can solve those, and solve the problem *in the general case*. Which is the one that it's important ant interesting. It's unimportant and uninteresting on the terms that Poettering/Sievers/Greg KH put forward, for us that wants control and does not want an all singing and dancing system (incl. kitchen sink). In my opinion the init system should be completely independent of the kernel with a well defined, generic, interface so that the user can choose and pick whatever pieces he/she wishes to run his system. Think Lego (as in small, well defined pieces that fit together in any way the user sees fit)... my wishing luck to the eudev fork (which, BTW, Greg also did). The few The way I read Greg's good luck was that it had quite a bit of a sarcastic tone... Was there really any need for him to say anything at all? I've previously had a lot of respect for Greg but this made me think quite a lot less of him... of us who *dare* to praise udev/systemd get an incredible amount of crap for it. We are nothing but fanbois or, in your words, udev has become like the cosmos: everything there is, and ever shall be. Really? I didn't knew that. You really sound like a fanboy... And I don't mean that in a derogatory way; it's just how I see your writing... Maybe we are doing it wrong. But as far as i can see, we are only expressing our opinion on technical grounds. We are not calling names Your opinions (technical or not) doesn't matter to me since (it seems) you have a very different goal than me with your system. I want you to enjoy whatever system you use but you shouldn't try to force that same system on to me. In that regard I see the eudev fork as a saviour. These are the technical grounds that I've seen you state: * fast boot time Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to XDM for me. The few seconds that it takes to boot from grub to login is of no matter (to me). * parallel service startup Nice to have but still irrelevant, see above. Sequential is also preferred from a trouble shooting perspective. Furthermore I like having the ability to stop a particular daemon if there something that needs fixing (pushing I when booting). * simple service unit files Simplicity is fine but to accomplish the same in your simple service file as in the example you brought forward (sshd) you need to hide a lot of stuff elsewhere. Not for me thanks, I'm a control freak. * good documentation I haven't read it so I won't touch this. Not a technical point though, more of an opinion. Although I agree that good documentation is very nice to have. * Really good in-site customization If I choose to upgrade a daemon, I should be interested in what changes, if any, that brings in configuration in order to not have any surprises later. If you think that's a good thing, that really sounds like you would be doing the OpenRC equivalent of: 'etc-update --automode -5' * control groups As I understand it, this depends on someone writing config files for the individual daemons. Noone is stopping Gentoo devs or anyone else from writing such. And I would, again, prefer to go through a good manual or a howto and do it myself so that I can understand the consequences, if I would want it. * unification I've tried quite a few distros over the years (starting with Redhat in the late 90'ies) and Gentoos OpenRC is by far the most sane system I've come across. Never going back to Redhat hell thank you! Standardizing the interfaces is fine but it's not ok to force a whole kitchen and sink solution in order to satisfy as many as possible. This is not the Gentoo way, as I understand it. Gentoo is all about choice. * you tell the daemon *what* to do, not *how* to do it It's good if you don't want to learn about what things you install and understand what the consequences are of different choices, in the config files. I run very few daemons on my desktop machine so it's not so time consuming to read up on/fix things etc. If I ever were to run a full blown server (esp. connected to the net) with lots of daemons I would be very hesitant to use any pre-configurations, seems suicidal to me. The only usage I see here of declarative scripts are when you don't care about what the machine is doing. Best regards Peter K
Re: [gentoo-user] Re: 3.7.1 SATA errors -- SOLVED
* fe...@crowfix.com fe...@crowfix.com [121227 10:08]: On Wed, Dec 26, 2012 at 09:41:54PM -0800, fe...@crowfix.com wrote: I configured a minimal kernel to test it sooner, and it booted to a prompt. Now I am compiling with my normal config, including encfs and a lot of other gorp, and will try it in the morning. My bloated fully-larded normal config version of the patched 3.7.1 kernel also works. dmesg logs match with the usual differences in USB assignments and a few messages which changed wording. The patch author says the patch is just waiting for the maintainers to approve it up the line. I do not know if that means it will be in 3.7.2. Thanks to everyone who helped here, especially with git bisect. Thank you for doing the git bisect and tracking this down (and Mark for pointing to the bugzilla.kernel.org bug.) Todd
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark David Dumlao wrote: On Thu, Dec 27, 2012 at 4:42 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 10:38 AM, Dale rdalek1...@gmail.com wrote: Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. From what I have read, they are saying what has worked for decades has been broken the whole time. Doesn't matter that it works for millions of users, its broken. Yes, that is exactly what they are saying. What I am pointing out, however, is that there is, informally, a _technical meaning_ for the word broken, which is that the specs don't match the implementation. And in the case of /usr, the specs don't match the implementation. For like, maybe all of the Linuxen. They say it is broken so they can fix it with a init thingy for EVERYONE. Sorry, that's like telling me my car has been broken for the last ten years when I have been driving it to town and it runs just fine. NOBODY is telling you your system or that the systems of millions of users out there aren't booting. You're assigning emotional baggage to technical language. To push your analogy, oh, your car is working just fine. Now anyone with a pair of spark plugs and a few tools may be able to start it without you, but your startup _works_. Now imagine some German engineer caring nothing about you lowly driver, and caring more about the car as a system, and he goes using fancy words like authentication systems and declaring that all cars have a flaw, or more incensingly, car security is fundamentally broken (Cue angry hordes of owners pitchfork and torching his house). Thing is, he's right, and if he worked out some way for software to verify that machine startup was done using the keys rather than spark plugs, he'd be doing future generations a favor in a dramatic reduction of carjackings. And if somehow it became mandated for future cars to have this added in addition to airbags and whatnot, it'd annoy the hell out of car makers but overall still be a good thing. And here the analogy is holding up: NOBODY is breaking into your car and forcefully installing some authentication system in its startup. And NOBODY is breaking into your servers and forcing you to switch to udev/systemd or merged /usr. You can still happily plow along with your system as is. Heck, you can even install current udev without changing your partition setup. Just modify the ebuild and have it install it into / instead of /usr. Or use an early bootup script. Or use an init thingy. The udev/systemd people sound like politicians. If anything, Lennart is the worst possible politician on the planet. He makes unpopular decisions, mucks around in stuff people don't want touched, talks snide and derisively, etc etc etc, because he's a nerd's nerd that knows nothing about PR and goodwill. The software is good, but that's about all he knows how to write. He's like DJB on crack. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none I think your analogy actually proves my point. Instead of just getting in the car and turning the key, they want to reinvent the engine and how it works. It doesn't matter that it is and has been working for decades, Thanks for proving my point tho. LOL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 8:13 AM, Dale rdalek1...@gmail.com wrote: I think your analogy actually proves my point. Instead of just getting in the car and turning the key, they want to reinvent the engine and how it works. It doesn't matter that it is and has been working for decades, Thanks for proving my point tho. LOL Dale hehe!! I guess you ain't one of those 'Global Warming' loonies that thinks our precious gas guzzling, smog belching cars are melting the glaciers and creatin' lots o' them hurricanes, 'eh? ;-) Sometimes technology just needs to move forward, but that doesn't mean you can't hold on to your musket and shoot them darn carpetbaggers if they trespass on your lawn, right? - Mark
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. He's like DJB on crack. Except DJB made every Linux system on this planet more reliable simple and secure through better coding practices and pointing out how buggy sendmail was. Lennart if anything will accomplish the exact opposite where systemd is used. -- ___ '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) ___
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
* Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then Kevin started to suggest that I know nothing about init systems, and I responded in kind. I did not and apologise if you took offense. I said perhaps badly that based on this posting, you don't have a great deal of experience in init systems. To me, your comment demonstrated that you don't on the vast plethora of init systems which all actually accomplish the same thing daemon wise just with varying reliability and functionality surrounding the process of doing so. No init system can tell a daemon how to do anything. So your comment. What to do, how to do actually has nothing to do with systemd. What does is having to learn a new more restrictive non intuitive and non externally useful or non universal *declarative* language. Like polkit/pkexecs javascript vs sudo. I will take sudoers every time and for good reason. Shell scripts usually spiral out of control is just utter FUD. I do realise you didn't originate this FUD, but it shouldn't be spread. Yes some corner case wants in init that some thought impossible in shell can get complex by scripting them but a small c tool following the unix philosophy simply becomes a shell command potentially useful in even unforeseeable cases. We are dealing with simple options meant for admins here. As I said OpenBSDs scripts are usually rediculously simple and should often really be called commands. As others have said the argument of function being in the scripts rather than the daemon is an irrelevance to using systemd. Systemd may try to become the whole OS but I'm fairly sure it hasn't plagiarised the c code to check and deal with ssh keys yet. That is rightly the job of the aptly named ssh-keygen and IMO some very simple shell code. The arch sshd script is only 44 lines and includes more than that to make the output colourful. The gentoo sshd script is actually simple too and doesn't do anything most of the time and is easily modifiable in absolutely predictable ways. -- ___ '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) ___
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/12 06:28, Graham Murray wrote: Michael Orlitzky mich...@orlitzky.com writes: The 'conntrack' module is supposed to be a superset of 'state', so most things should be compatible. You really have two warnings there; the first is for the state - conntrack switch, and the second is because you're missing the --state flag in your rules. In your example, you turn on the state matching, iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED but you don't specify *which* state(s) you want to match. It wants you to specify --state SOMETHING. I'd guess that it used to interpret no state as any state. The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. Youch, thanks, I'll keep an eye out for this when iptables wants a bump. I already keep the rules in a script, but it sounds like this will clobber the running rules after e.g. a reboot. My first -m state rule is, iptables -A INPUT -p ALL -m state \ --state ESTABLISHED,RELATED -j ACCEPT And if what you say is true, I'd be in deep shit if it reset to, iptables -A INPUT -p ALL -m state -j ACCEPT without a warning. I think that this is a serious enough change in behaviour that an elog warning should have been issued. It's not stable yet, right? File a bug (and CC me, please).
Re: [gentoo-user] Re: problem starting openvpn after recenet upgrade
On 12/27/12 16:00, Jörg Schaible wrote:
Joseph wrote:
I'm having problem starting openvpn after recent upgrade.
When I try to start it I get a normal respond:
openvpn.client_clinic_atom start
* Starting openvpn.client_clinic_atom ...[ ok ]
* WARNING: openvpn.client_clinic_atom has started, but is inactive
but ifconfig is not showing this connection in addition it looks strange,
not as it used to:
ifconfig
eth1: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500
inet 10.0.0.100 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::21b:21ff:feb8:27b6 prefixlen 64 scopeid 0x20link
ether 00:1b:21:b8:27:b6 txqueuelen 1000 (Ethernet)
RX packets 16129 bytes 9087618 (8.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15573 bytes 2667489 (2.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xfddc-fdde
lo: flags=73UP,LOOPBACK,RUNNING mtu 16436
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10host
loop txqueuelen 0 (Local Loopback)
RX packets 1218 bytes 1433926 (1.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1218 bytes 1433926 (1.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Known problem. Rebuild openvpn and it works again. The build adds some hard
coded paths for some net-tools utilities and the location of ifconfig has
changed :-/
- Jörg
Yes, you are correct. Rebuilding openvpn worked; thank you.
{@} * {@} * {@} Happy New Year!
{@} * {@} * {@} * {@} Wish you extra ordinary good luck!
{@} * {@} * {@}
\ \ \ 2013 / / /
--
Joseph
Re: [gentoo-user] Building an initramfs into the kernel
On Wed, Dec 26, 2012 at 3:50 PM, Mark Knecht markkne...@gmail.com wrote: On Wed, Dec 26, 2012 at 3:03 PM, Neil Bothwick n...@digimed.co.uk wrote: On Wed, 26 Dec 2012 14:09:34 -0800, Mark Knecht wrote: At this point I don't know that 1) the image is actually in the kernel, or 2) that my init thingy ;-) image would work, but at least the process of putting it together is verifiable. That's why I put in all the debug stuff, so I could watch the progress of the script as it ran. OK, I'll look at combining that part my my scripts, or just using yours, etc. Thanks for the help, Mark Neil, One more question if I might. What's the simplest way to regenerate the kernel when there are no kernel changes but you have changes to the programs that are going into the initramfs? make clean seems like overkill to me, and it's very slow to boot. I suspect that one of the simplest failures on an initramfs is that you update something that's contained in the initramfs, mdadm or busybox or whatever, and then don't get that new stuff into the initramfs. Seems like I need to be right on top of what I'm keeping in it and make sure a new kernel gets generated any time those packages are updated. Correct? Anyway, I'm wondering how you manage that? Should be booting my first kernel with the initramfs in it shortly. We'll see how that goes. Thanks, Mark
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 12:13 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Thu, Dec 27, 2012 at 4:42 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 10:38 AM, Dale rdalek1...@gmail.com wrote: Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. From what I have read, they are saying what has worked for decades has been broken the whole time. Doesn't matter that it works for millions of users, its broken. Yes, that is exactly what they are saying. What I am pointing out, however, is that there is, informally, a _technical meaning_ for the word broken, which is that the specs don't match the implementation. And in the case of /usr, the specs don't match the implementation. For like, maybe all of the Linuxen. They say it is broken so they can fix it with a init thingy for EVERYONE. Sorry, that's like telling me my car has been broken for the last ten years when I have been driving it to town and it runs just fine. NOBODY is telling you your system or that the systems of millions of users out there aren't booting. You're assigning emotional baggage to technical language. To push your analogy, oh, your car is working just fine. Now anyone with a pair of spark plugs and a few tools may be able to start it without you, but your startup _works_. Now imagine some German engineer caring nothing about you lowly driver, and caring more about the car as a system, and he goes using fancy words like authentication systems and declaring that all cars have a flaw, or more incensingly, car security is fundamentally broken (Cue angry hordes of owners pitchfork and torching his house). Thing is, he's right, and if he worked out some way for software to verify that machine startup was done using the keys rather than spark plugs, he'd be doing future generations a favor in a dramatic reduction of carjackings. And if somehow it became mandated for future cars to have this added in addition to airbags and whatnot, it'd annoy the hell out of car makers but overall still be a good thing. I think your analogy actually proves my point. Instead of just getting in the car and turning the key, they want to reinvent the engine and how it works. It doesn't matter that it is and has been working for decades, I think your reaction proves my point about angry mobs torching his home without understanding what's being proposed. Your fine reading comprehension once again failed to catch the notion that in my analogy, all he invented was a mechanism that makes sure it was a key, not a spark plug, that did the starting. i.e., you're asking literally for a turnkey system, and that's literally what he invented, except that the system guarantees that it's a key that was turned. You have not said a THING about your misunderstanding of the use of the word _broken_ and you're continuing to peddle your hate-boner even after it's been shown that you're confused. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] IPTABLES syntax change?
Michael Orlitzky wrote: My first -m state rule is, iptables -A INPUT -p ALL -m state \ --state ESTABLISHED,RELATED -j ACCEPT That was mine, too (you can omit -p in this case, can't you?). And if what you say is true, I'd be in deep shit if it reset to, iptables -A INPUT -p ALL -m state -j ACCEPT without a warning. It *was* resetted here. I just noticed it reading this discussion. Don't exactly know what the stateless rule did (perhaps just nothing?), but since I didn't notice it for a pretty long time, it can't have been all to bad?! At least, it didn't crash the whole system :-) But I would have appreciated at least an update notice, too! -Matt
Re: [gentoo-user] Re: problem starting openvpn after recenet upgrade
Joseph wrote: Yes, you are correct. Rebuilding openvpn worked; thank you. As far as I have seen, you can set USE=iproute2 for OpenVPN which seems to use iproute2 instead of net-tools - should avoid your problem, too. -Matt
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark David Dumlao wrote: I think your reaction proves my point about angry mobs torching his home without understanding what's being proposed. Your fine reading comprehension once again failed to catch the notion that in my analogy, all he invented was a mechanism that makes sure it was a key, not a spark plug, that did the starting. i.e., you're asking literally for a turnkey system, and that's literally what he invented, except that the system guarantees that it's a key that was turned. You have not said a THING about your misunderstanding of the use of the word _broken_ and you're continuing to peddle your hate-boner even after it's been shown that you're confused. -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate [ ] soon [x] none So I guess Linus is confused to? You think he is just a hate-boner? I would think Linus if anyone knows what he is talking about. Maybe you need to go talk to him about his feeling on the direction of udev/systemd. Good luck with that. Name calling, lost argument. No more facts. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. The spec - or implementation - of / and /usr separation is broken and has been for quite a while now. Nobody here's even bothered answering how the modern Gentoo distro / sysad would survive /usr being out of sync with /, for instance, or the fact that some udev programs tend to be located in /usr, or even just a solid detailed specification on the precise criteria for inclusion into /. Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. You'd think, for instance, something as clear cut as filesystem manipulation tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin. But no it's not. Or - for crying out loud, at least a text editor that isn't ed. Again, the broken state of the / and /usr split is a different thing from the usefulness state of your own already installed distro. TLDR: The spec is broken. He's like DJB on crack. Except DJB made every Linux system on this planet more reliable simple and secure through better coding practices and pointing out how buggy sendmail was. Lennart if anything will accomplish the exact opposite where systemd is used. If you have something more than FUD to back up your technical claims, go ahead. You're directly claiming that wherever systemd is used, the system will be less reliable and secure, and that Lennart isn't pointing out buggy behaviors in - what's the analogue for sendmail? oh yeah - SysVInit scripts. To carry the analogy, DJB's main point was that the size of the code was one of - if not the - most important factors in increasing code quality and security, and worked to make qmail and its configuration about as spartan as you can get. That's kind of the point of systemd unit files, trimming the boilerplate size to reduce gotchas like init scripts failing to detect whether a service is running or not, or if its dependencies have been started. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 2:15 AM, Dale rdalek1...@gmail.com wrote: So I guess Linus is confused to? In your head, and only in your head, you're agreeing with Linus. Linus was talking about a different bug entirely from the one you're talking about. The bug you're talking about: you go on and on about people saying that your personal system is broken when it's been working for years. Again, NOBODY said that. What was said, what you are not able to refute, is that yes, the case for the / and /usr split IS broken, and something needs to be done about that moving forward. Name calling, lost argument. No more facts. I've repeatedly proposed technical solutions to your issues with the fact that udev is doing something about that and you continue to whine all night about the bogey-men breaking into your boxes. In fact, between just you and me, I believe I'm the only one who backed up anything he said with anything even remotely approaching technical merit. 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. None of this is being prevented by the vengeful Lennart you're so afraid of. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 1:22 PM, Mark David Dumlao madum...@gmail.comwrote: On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. The spec - or implementation - of / and /usr separation is broken and has been for quite a while now. Nobody here's even bothered answering how the modern Gentoo distro / sysad would survive /usr being out of sync with /, for instance, If the basics are kept in /, with prod-additionals kept in /usr, then you should be able to boot to basics, and restore /usr. or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. You'd think, for instance, something as clear cut as filesystem manipulation tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin. But no it's not. Or - for crying out loud, at least a text editor that isn't ed. I'd say that warrants bug reports against those programs. Also, isn't busybox under /? I think it has nano built-in. Again, the broken state of the / and /usr split is a different thing from the usefulness state of your own already installed distro. TLDR: The spec is broken. It's not that the spec is broken. It's that the spec doesn't lay out every single detail imaginable, and as a consequence, people assuming that the spec should be able to do their thinking for them assume the spec is broken when it's silent on a given query. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 1:31 PM, Mark David Dumlao madum...@gmail.comwrote: On Fri, Dec 28, 2012 at 2:15 AM, Dale rdalek1...@gmail.com wrote: So I guess Linus is confused to? In your head, and only in your head, you're agreeing with Linus. Linus was talking about a different bug entirely from the one you're talking about. The bug you're talking about: you go on and on about people saying that your personal system is broken when it's been working for years. Again, NOBODY said that. What was said, what you are not able to refute, is that yes, the case for the / and /usr split IS broken, and something needs to be done about that moving forward. Name calling, lost argument. No more facts. I've repeatedly proposed technical solutions to your issues with the fact that udev is doing something about that and you continue to whine all night about the bogey-men breaking into your boxes. In fact, between just you and me, I believe I'm the only one who backed up anything he said with anything even remotely approaching technical merit. 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. If you'd read the thread (and/or related ones), you'd know he tried to go the initrd route, and spent a solid week on the project. You're not talking to someone who hasn't tried to tread the path. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol mike...@gmail.com wrote: SNIP 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. If you'd read the thread (and/or related ones), you'd know he tried to go the initrd route, and spent a solid week on the project. You're not talking to someone who hasn't tried to tread the path. hehe! And while I have a initramfs external to 3.2.1 a kernel working on a RAID6 / system, my first attempt at building the initramfs into gentoo-sources-3.6.11 as per Neil's pointers resulted in the RAID6 kicking one drive and not booting, so there is pain out there to be had. ;-) I'll post more in my thread about how I fix it and move forward later. Again, I don't really care about the pain - in a sick sense I sort of like it (more if it wore high heels...) - but I'm gonna learn this initramfs stuff and make it work because I suspect it's at least a good thing to know. It ain't only you Dale. I have (!)fun(!) with this stuff too... ;-) Cheers, Mark
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/12 12:52, Matthias Hanft wrote: Michael Orlitzky wrote: My first -m state rule is, iptables -A INPUT -p ALL -m state \ --state ESTABLISHED,RELATED -j ACCEPT That was mine, too (you can omit -p in this case, can't you?). Yeah, it just makes the indentation line up in my case. And if what you say is true, I'd be in deep shit if it reset to, iptables -A INPUT -p ALL -m state -j ACCEPT without a warning. It *was* resetted here. I just noticed it reading this discussion. Don't exactly know what the stateless rule did (perhaps just nothing?), but since I didn't notice it for a pretty long time, it can't have been all to bad?! At least, it didn't crash the whole system :-) But I would have appreciated at least an update notice, too! I confirmed and opened a bug: https://bugs.gentoo.org/show_bug.cgi?id=448906 Thanks again to Graham for pointing this out.
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Am Sonntag, 23. Dezember 2012, 19:03:25 schrieb Nuno J. Silva: Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? because some people decided, that fsck or that dynamic /dev/ populator depends on stuff in /usr? which is the reason for this thread? How do you mount a filesystem if you don't even have a dev node in the first place? -- #163933
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva: On 2012-12-23, Alan Mackenzie wrote: On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: On 2012-12-23, Alan McKinnon wrote: On Sun, 23 Dec 2012 12:22:24 +0200 nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: On 2012-12-18, Alan McKinnon wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: This sentence summarizes my understanding of your post nicely: Now, why is /usr special? It's because it contains executable code the system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. What about just mounting /usr as soon as the system boots? Please read the thread next time. The topic under discussion is solutions to the problem of not being able to do exactly that. Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? Because certain people with influence have rearranged the filesystem so that programs within /usr are absolutely necessary for booting; they are needed _before_ init has a chance to mount /usr. So either /usr has to be in the root partition, or crazy kludges need to be used to mount /usr before the kernel runs init. I surely don't know the udev architecture well enough, but if this is all done by the udev daemon, can't we just mount /usr before the daemon is started? The only needed things should be mount (which is under /bin here) and /etc/fstab. and a device node in /dev - like /dev/sda2. And how do you get that one without udev? oops? -- #163933
[gentoo-user] Re: Re: problem starting openvpn after recenet upgrade
Matthias Hanft wrote: Joseph wrote: Yes, you are correct. Rebuilding openvpn worked; thank you. As far as I have seen, you can set USE=iproute2 for OpenVPN which seems to use iproute2 instead of net-tools - should avoid your problem, too. If iprout2 is relocated, it will fail for openvpn exactly the same miserably way. - Jörg
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, 27 Dec 2012 20:43:12 +0100, Volker Armin Hemmann wrote: and a device node in /dev - like /dev/sda2. And how do you get that one without udev? CONFIG_DEVTMPFS=y Of course, that only helps if /usr is on a plain old disk block device. -- Neil Bothwick No, you *can't* call 999 now. I'm downloading my mail. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 2:43 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva: On 2012-12-23, Alan Mackenzie wrote: On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: On 2012-12-23, Alan McKinnon wrote: On Sun, 23 Dec 2012 12:22:24 +0200 nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: On 2012-12-18, Alan McKinnon wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: This sentence summarizes my understanding of your post nicely: Now, why is /usr special? It's because it contains executable code the system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. What about just mounting /usr as soon as the system boots? Please read the thread next time. The topic under discussion is solutions to the problem of not being able to do exactly that. Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? Because certain people with influence have rearranged the filesystem so that programs within /usr are absolutely necessary for booting; they are needed _before_ init has a chance to mount /usr. So either /usr has to be in the root partition, or crazy kludges need to be used to mount /usr before the kernel runs init. I surely don't know the udev architecture well enough, but if this is all done by the udev daemon, can't we just mount /usr before the daemon is started? The only needed things should be mount (which is under /bin here) and /etc/fstab. and a device node in /dev - like /dev/sda2. And how do you get that one without udev? oops? Yeah, the oops is on the part of the udev team, which decided to put a critical piece of software there. Which is the origin of this whole uproar for the past year or so. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On 2012-12-27, Volker Armin Hemmann wrote: Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva: On 2012-12-23, Alan Mackenzie wrote: On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: On 2012-12-23, Alan McKinnon wrote: On Sun, 23 Dec 2012 12:22:24 +0200 nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: On 2012-12-18, Alan McKinnon wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: This sentence summarizes my understanding of your post nicely: Now, why is /usr special? It's because it contains executable code the system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. What about just mounting /usr as soon as the system boots? Please read the thread next time. The topic under discussion is solutions to the problem of not being able to do exactly that. Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? Because certain people with influence have rearranged the filesystem so that programs within /usr are absolutely necessary for booting; they are needed _before_ init has a chance to mount /usr. So either /usr has to be in the root partition, or crazy kludges need to be used to mount /usr before the kernel runs init. I surely don't know the udev architecture well enough, but if this is all done by the udev daemon, can't we just mount /usr before the daemon is started? The only needed things should be mount (which is under /bin here) and /etc/fstab. and a device node in /dev - like /dev/sda2. And how do you get that one without udev? oops? Please try booting your system and getting to a shell before udevd gets started. Then, please do ls /dev. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! However... Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. Don't forget that FHS is heavily an after-the-fact descriptive document of what is happening in practice, with heavy rationale sections describing what's going on in the wild. Before you can fix FHS, you first have to fix the practice, then FHS can get amended to reflect what's going on. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Now that doesn't translate to epic disasters of biblical proportion, fire and brimstone, rivers and seas boiling, dogs and cats living together, mass hysteria - because it's just a collection of hard to pin down essential boot programs - but it does translate to an unsustainable practice in distro development / package management. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM Purpose: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. 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. 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. * some teasers: [1] udev rules themselves being a case in point. I mean, do the requisite binaries belong in /? For example, there's a virtualbox udev rule in /usr that doesn't mount other filesystems or stop udev from starting. However, given the right race conditions, udev will fail to start the requisite script because /usr isn't mounted. [2] fuse-based filesystems allow an administrator the crazy possibility of, for example, demanding that /home be an ssh connection. Should the ssh client belong in /? ftp? substitute any arbitrary client program. [3] a fuse-based filesystem depends on a local network service being started. For example, someone writes a crazy fuse mysql browser that also is coincidentally mounted at boot time. Should the mysqld service belong in /? ldap? substitute any arbitrary server program. [4] /root (which is why it's separated from /home) contains docs and custom utilities used by root user for recovery. Unfortunately, there's a lot of perl scripts there specifically for doing filesystem checks / reports. Should perl be in in /? substitute any scripting language. The point is not whether _you_ can come up with an answer for
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. However... Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. Don't forget that FHS is heavily an after-the-fact descriptive document of what is happening in practice, with heavy rationale sections describing what's going on in the wild. Before you can fix FHS, you first have to fix the practice, then FHS can get amended to reflect what's going on. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. Now that doesn't translate to epic disasters of biblical proportion, fire and brimstone, rivers and seas boiling, dogs and cats living together, mass hysteria - because it's just a collection of hard to pin down essential boot programs - but it does translate to an unsustainable practice in distro development / package management. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM Purpose: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. 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. 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. * some teasers: [1] udev rules themselves being a case in point. I mean, do the requisite binaries belong in /? Udev is a dispatcher. Actually, in substance, it's a piece of the kernel that resides in userland; it exists because it was decided back around the time of devfs that what devfs was doing is something that ought to be outside the kernel. In reality, it's effectively been a userland kernel-support process its entire life. What should probably happen is that udev should be fixed to defer hotplug events until a rules file is able to sucessfully handle it. And rules files should perform sanity checking and
[gentoo-user] gnome 3.6 ... and related thoughts
greets ... today (at least in my timezone ;-) ) I saw gnome-3.6-related ebuilds coming up on my ~amd64 box ... I ran a backup (yes, experience ...) and emerged stuff ... so far it runs OK. There are changes and new features and I am still exploring stuff. The general question: is it a bug or a feature? ;-) for example Alt-leftclick doesn't allow me to move windows right now. bug? - What I'd like to discuss: how to start over for a given user? For example, I want to get rid of old stuff from gnome-1.x/2.x or so (I think of my ~-directory, not the overall system). Or even bigger, does it make sense to drop stuff from all those dot-directories in ~ from time to time (e.g. at bigger GUI-upgrades) and only keep some important ones? For example I would keep core stuff like .gnupg .ssh .bashrc .thunderbird (in my case) ... but I am sure there is loads of stuff to get rid of. Maybe most of it doesn't make a difference (hdd-space is cheap anyways) and isn't even read anymore by recent versions of software. But maybe some files/dirs should get dumped and forgotten. Do you gentoo-users have any opinions on this? Does it make any sense to re-create my main user(-dir)? Stefan
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark Knecht wrote: On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol mike...@gmail.com wrote: SNIP 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. If you'd read the thread (and/or related ones), you'd know he tried to go the initrd route, and spent a solid week on the project. You're not talking to someone who hasn't tried to tread the path. hehe! And while I have a initramfs external to 3.2.1 a kernel working on a RAID6 / system, my first attempt at building the initramfs into gentoo-sources-3.6.11 as per Neil's pointers resulted in the RAID6 kicking one drive and not booting, so there is pain out there to be had. ;-) I'll post more in my thread about how I fix it and move forward later. Again, I don't really care about the pain - in a sick sense I sort of like it (more if it wore high heels...) - but I'm gonna learn this initramfs stuff and make it work because I suspect it's at least a good thing to know. It ain't only you Dale. I have (!)fun(!) with this stuff too... ;-) Cheers, Mark Well, I have enough pain already. I don't need my computer adding to it. Using something that I shouldn't need and certainly don't want to use is not my first or second option. If I liked pain like that, I'd go break a leg or something. :/ Just saying. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. This is where you stumble. It's not a fix. It's a WONTFIX. It's a make a lot of noise so that something else gets fixed because this is outside of our domain and we're not going to be responsible for it as it wasnt our bug in the first place. And that something else happens to be the / and /usr split conflicting with the user programs. If you give the squeaky wheel the grease - as in merge / and /usr - you apply the fix independently of udev, which was simply installed to the /usr prefix. THAT is a solution - one independent of udev and again, does not depend on initr*. You don't have to. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. Two things. First, I'm not saying that a spec should specify everything. I am saying, however, that there are specific cases that is within its domain to specify and that it should be specifying. And because those cases generate conflicts, the fact that they aren't is a bug. Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different hosts if it depends on libraries in /? http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Many distros place fundamental libraries that many programs in /usr depend on in /lib. Especially bad for Gentoo - libraries in /lib may be recompiled as same-version variants if you want to change the USE flags, resulting in clients that don't synchronously recompile their own libraries in /lib to both silently and noisily fail. In other words, many programs in /usr in practice are functionally inseparable from the libraries in /, conflicting with the notion that they were properly shared in the first place. Compare this with the
Re: [gentoo-user] Good/better/best filesystem for large, static video library?
On Thu, 27 Dec 2012 14:57:09 +0100 Michael Hampicke gentoo-u...@hadt.biz wrote: Migrating my NAS to ZFS is something that has been floating around my head for a longer time. But I am not really sure if I want to switch from gentoo to FreeBSD on my NAS. zfsonlinux is there, but it's first release was early 2011, so it's still pretty young. I guess for the time being I stick to an old credo: never touch a running system My main requirement was simple: the NAS must be no-touch. I'm perfectly happy fiddling till 3am with every other system I have, but not that one :-) I needed something that family could use too with all reasonable share types active (the family can pick how they want to connect), and that must stay the same for long periods. I figured the only way to get that was to rig it so I couldn't fiddle too much. FreeBSD is familiar territory so FreeNAS was the logical choice. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 10:56:52 +0700 Pandu Poluan pa...@poluan.info wrote: In case you haven't noticed, since Windows 7 (or Vista, forget which) Microsoft has even went the distance of splitting between C: (analogous to /usr) and 'System Partition' (analogous to /). The boot process is actually handled by the 100ish MB 'System Partition' before being handed to C:. This will at least give SysAdmins a fighting chance of recovering a botched maintenance. (Note: Said behavior will only be visible if installing onto a clean hard disk. If there are partitions left over from previous Windows installs, Win7 will not create a separate 'System Partition') So, if Microsoft saw the light, why does Red Hat sunk into darkness instead? I zone out of work-related stuff for three days to enjoy presents instead, and look what happens to the thread :-) I think I've said all I need to say on this matter, I'm not out to prove any point really and don't have a dog in this fight. I might not agree with how Lennart and RH are proceeding with implementation, but I do agree with the generally stated engineering problem at the core of the debate. I'm not sure about Microsoft's motivations in what you describe. My first reaction is that the Great Circle of IT Life is turning and MS are trying something new for them. Whether it's applicable to us here as an illustration remains to be seen - I know very little about Windows so can't even begin to draw sensible parallels. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] IPTABLES syntax change?
On Thu, Dec 27, 2012 at 11:28:15AM +, Graham Murray wrote The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. Thanks for pointing that out. I looked back at an archived version, and it had stuff like... -A ICMP_IN -p icmp -m state --state NEW -j UNSOLICITED -A TCP_IN -p tcp -m state --state NEW -m tcp -j UNSOLICITED -A UDP_IN -p udp -m state --state NEW -j UNSOLICITED I.e. new external connection attempts were rejected, except for my lan which bypasses this rule so I can scp/ssh etc between my machines. No wonder I was puzzled by what I saw. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] E17 lock screen
On Saturday 22 Dec 2012 01:29:57 Kevin Brandstatter wrote: So e17 just came out and ive been using for a bit. The only problem ive had with it is that i cant check the option to lock the screen on suspend. I don't think this is a problem on some of the other distributions so thought it could be a policy problem on gentoo. Curious if anyone else uses e17/has this problem and maybe a fix. or just for suggestions of where to look I can't select it here either, but I suspect that this may be because I do not use xscreenlock or equivalent. Have you tried posting either at the e17 or the enlightenm...@gentoo.org mailing lists? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, Dec 27, 2012 at 10:00 AM, pk pete...@coolmail.se wrote: On 2012-12-27 02:14, Canek Peláez Valdés wrote: I really think that's the crux of the matter Pandou: udev/systemd serves to the wants of the many. The eudev fork serves to the wants of systemd+udev serves the large mass (users of mainly Fedora and other distros using systemd) that doesn't care/know computers. Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. a very few which really don't want an initramfs, when it has a lot of technical advantages. It has some problems, of course, but we can solve those, and solve the problem *in the general case*. Which is the one that it's important ant interesting. It's unimportant and uninteresting on the terms that Poettering/Sievers/Greg KH put forward, for us that wants control and does not want an all singing and dancing system (incl. kitchen sink). In my opinion the init system should be completely independent of the kernel with a well defined, generic, interface so that the user can choose and pick whatever pieces he/she wishes to run his system. Think Lego (as in small, well defined pieces that fit together in any way the user sees fit)... And how's that changed? If you want control, you will *always* have control. The source code is out there; what more control do you need? my wishing luck to the eudev fork (which, BTW, Greg also did). The few The way I read Greg's good luck was that it had quite a bit of a sarcastic tone... Was there really any need for him to say anything at all? I've previously had a lot of respect for Greg but this made me think quite a lot less of him... That's how you choose to interpret it, and I'm pretty sure it was not the way Greg said it. of us who *dare* to praise udev/systemd get an incredible amount of crap for it. We are nothing but fanbois or, in your words, udev has become like the cosmos: everything there is, and ever shall be. Really? I didn't knew that. You really sound like a fanboy... And I don't mean that in a derogatory way; it's just how I see your writing... It does sound derogatory... Maybe we are doing it wrong. But as far as i can see, we are only expressing our opinion on technical grounds. We are not calling names Your opinions (technical or not) doesn't matter to me since (it seems) you have a very different goal than me with your system. I want you to enjoy whatever system you use but you shouldn't try to force that same system on to me. In that regard I see the eudev fork as a saviour. What *I* am forcing on *anyone*? How could *I* force *anything* on *anyone*? I'm just stating why I believe udev/systemd is a nice solution to the general problem. That's all: I'm not a developer, I'm not a distro planer; I'm not in any way capable to enforce anything on anyone. And I, if I'm allowed to repeat it, have never called names on anyone. I'm just stating my opinion; how could you twist that into the idea that I'm trying to force that same system on to me? Really? These are the technical grounds that I've seen you state: * fast boot time Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to XDM for me. The few seconds that it takes to boot from grub to login is of no matter (to me). It matters to me. A lot. Specially in my laptop (I follow vanilla-sources unstable, so I reboot relatively often), in my media center (same reasons). In my servers certainly the hardware initialization phase is longer; but (IMO) that makes even more important the speed gains from grub to userspace. Please, understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. * parallel service startup Nice to have but still irrelevant, see above. Sequential is also preferred from a trouble shooting perspective. Furthermore I like having the ability to stop a particular daemon if there something that needs fixing (pushing I when booting). Relevant for me, see above. And that's another thing I hate about the shell init scripts; problems get workarounded instead of properly fixed. If there is a problem at boot time *it should be fixed where the problem lives*, not workarounded with shell hackery. Again, please understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. * simple service unit files Simplicity is fine but to accomplish the same in your simple service file as in the example you brought forward (sshd) you need to hide a lot of stuff elsewhere. Not for me thanks, I'm a control freak. I'm not; let the machines do the work. The least I have to think about my system, the better; I care only for it to work. Again, please
Re: [gentoo-user] Building an initramfs into the kernel
On Thu, Dec 27, 2012 at 9:33 AM, Mark Knecht markkne...@gmail.com wrote: On Wed, Dec 26, 2012 at 3:50 PM, Mark Knecht markkne...@gmail.com wrote: On Wed, Dec 26, 2012 at 3:03 PM, Neil Bothwick n...@digimed.co.uk wrote: On Wed, 26 Dec 2012 14:09:34 -0800, Mark Knecht wrote: At this point I don't know that 1) the image is actually in the kernel, or 2) that my init thingy ;-) image would work, but at least the process of putting it together is verifiable. That's why I put in all the debug stuff, so I could watch the progress of the script as it ran. OK, I'll look at combining that part my my scripts, or just using yours, etc. Thanks for the help, Mark Neil, One more question if I might. What's the simplest way to regenerate the kernel when there are no kernel changes but you have changes to the programs that are going into the initramfs? make clean seems like overkill to me, and it's very slow to boot. SNIP Answering self: The Gentoo wiki covered this at the end: http://en.gentoo-wiki.com/wiki/Initramfs I tried it and it seemed to work, although I've not yet successfully booted this kernel so there may well be some issues left to deal with. Cheers
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, Dec 27, 2012 at 10:29 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then Kevin started to suggest that I know nothing about init systems, and I responded in kind. I did not and apologise if you took offense. Apology accepted, and I also apologise if my response was out of line/with bad tone. I said perhaps badly that based on this posting, you don't have a great deal of experience in init systems. Well, I haven't wrote any, but I used the ones in OpenBSD, Solaris, Linux SysV, OpenRC systemd, and Windows NT. Used as in administering several machines with them. So, I have some experience. To me, your comment demonstrated that you don't on the vast plethora of init systems which all actually accomplish the same thing daemon wise just with varying reliability and functionality surrounding the process of doing so. No init system can tell a daemon how to do anything. You are wrong. In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, and to a lesser degree, it happens when you use a shell to launch daemons. So your comment. What to do, how to do actually has nothing to do with systemd. What does is having to learn a new more restrictive non intuitive and non externally useful or non universal *declarative* language. Like polkit/pkexecs javascript vs sudo. I will take sudoers every time and for good reason. I'm not 100% happy with Polkit use of JS, but having finally understood how it works, I think is kind of nice. I believe role verification and authentication is one of the tasks where a Turing-complete language actually be justified. Shell scripts usually spiral out of control is just utter FUD. I do realise you didn't originate this FUD, but it shouldn't be spread. Yes some corner case wants in init that some thought impossible in shell can get complex by scripting them but a small c tool following the unix philosophy simply becomes a shell command potentially useful in even unforeseeable cases. Funny that you said that; if you are really interested, take a look at /usr/lib/systemd in a systemd machine. Almost all of those are really simple C programs that do one thing, and one thing only. Most of them don't reach the 100 lines of C code. To me, a Turing-complete language for starting and stoping services is overkill. And also there is the Halting Problem; you simply cannot workaround that. We are dealing with simple options meant for admins here. As I said OpenBSDs scripts are usually rediculously simple and should often really be called commands. As others have said the argument of function being in the scripts rather than the daemon is an irrelevance to using systemd. Systemd may try to become the whole OS but I'm fairly sure it hasn't plagiarised the c code to check and deal with ssh keys yet. That is rightly the job of the aptly named ssh-keygen and IMO some very simple shell code. Yeah, running from the install script/Makefile/post-inst-hook/whatever. Not the init system. IMO. The arch sshd script is only 44 lines and includes more than that to make the output colourful. The gentoo sshd script is actually simple too and doesn't do anything most of the time and is easily modifiable in absolutely predictable ways. I'm not arguing that; I'm arguing that it can be done even more simple, and even more easily modifiable. But like a said to Pandou; let's just agree to disagree. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] gnome 3.6 ... and related thoughts
On Thu, Dec 27, 2012 at 3:46 PM, Stefan G. Weichinger li...@xunil.at wrote: greets ... today (at least in my timezone ;-) ) I saw gnome-3.6-related ebuilds coming up on my ~amd64 box ... I ran a backup (yes, experience ...) and emerged stuff ... so far it runs OK. There are changes and new features and I am still exploring stuff. The general question: is it a bug or a feature? ;-) for example Alt-leftclick doesn't allow me to move windows right now. bug? No, it works that way. You could changed in previous versions with the /apps/metacity/general/mouse_button_modifier key in gconftool-2, but now it's gone. I don't know if anyone is working on bring it back. What I'd like to discuss: how to start over for a given user? For example, I want to get rid of old stuff from gnome-1.x/2.x or so (I think of my ~-directory, not the overall system). Or even bigger, does it make sense to drop stuff from all those dot-directories in ~ from time to time (e.g. at bigger GUI-upgrades) and only keep some important ones? For example I would keep core stuff like .gnupg .ssh .bashrc .thunderbird (in my case) ... but I am sure there is loads of stuff to get rid of. Maybe most of it doesn't make a difference (hdd-space is cheap anyways) and isn't even read anymore by recent versions of software. But maybe some files/dirs should get dumped and forgotten. Do you gentoo-users have any opinions on this? Does it make any sense to re-create my main user(-dir)? I started over with a clean $HOME, and I moved back the non-GNOME stuff (.ssh, .gnupg, .bash*, etc). But maybe it was overkill. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Mon, 24 Dec 2012 15:14:11 + Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Are there any other cases, apart from emotional attachment based on inertia, where a separate / and /usr are desirable? As I see it, there is only the system, and it is an atomic unit. You should really read the thread before posting. You quoted a hypothical question I posed[1] which follows directly on from something I described in the previous paragraph. You should really retain context in what you decide to snip, as you have changed the entire meaning and intent of what I said and asked. [1] The question was literally an RFC - a request for people to comment. I have no strict engineering or configuration need for / and /usr to be separate; I know of one setup configuration that requires it, I asked who needs it for different reasons and why - not as a debate point, but as a learning point. Does that sufficiently answer the thought that prompted you to reply? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/2012 06:11 PM, Walter Dnes wrote: On Thu, Dec 27, 2012 at 11:28:15AM +, Graham Murray wrote The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. Thanks for pointing that out. I looked back at an archived version, and it had stuff like... -A ICMP_IN -p icmp -m state --state NEW -j UNSOLICITED -A TCP_IN -p tcp -m state --state NEW -m tcp -j UNSOLICITED -A UDP_IN -p udp -m state --state NEW -j UNSOLICITED I.e. new external connection attempts were rejected, except for my lan which bypasses this rule so I can scp/ssh etc between my machines. No wonder I was puzzled by what I saw. Ah, yes, the original problem. Once you've upgraded, you should be able to add all of your old --state rules normally, albeit with a warning. The new iptables will translate them to conntrack rules, and you can `/etc/init.d/iptables save` the result. The upgrade just fails in a horrible way.
Re: [gentoo-user] gnome 3.6 ... and related thoughts
Am 28.12.2012 00:45, schrieb Canek Peláez Valdés: No, it works that way. You could changed in previous versions with the /apps/metacity/general/mouse_button_modifier key in gconftool-2, but now it's gone. I don't know if anyone is working on bring it back. I *liked* the old way ... is there any explanation why removing this improves things? How is it supposed to work now? Sorry, I could browse docs, sure ... I started over with a clean $HOME, and I moved back the non-GNOME stuff (.ssh, .gnupg, .bash*, etc). But maybe it was overkill. Thanks for sharing. I will maybe try that tomorrow (late here). usermod -l ... ? ;-) S
Re: [gentoo-user] gnome 3.6 ... and related thoughts
2012/12/28 Stefan G. Weichinger li...@xunil.at Am 28.12.2012 00:45, schrieb Canek Peláez Valdés: No, it works that way. You could changed in previous versions with the /apps/metacity/general/mouse_button_modifier key in gconftool-2, but now it's gone. I don't know if anyone is working on bring it back. I *liked* the old way ... is there any explanation why removing this improves things? How is it supposed to work now? Sorry, I could browse docs, sure ... I can't tell you how the window move works now. The old way of configuring was removed and won't be included in the new 3.X branch anymore, Somehow the GNOME people don't like that the user can configure his/her GNOME experience. They want that every GNOME 3 looks and feels the same. Maybe interesting to read: http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ I think we had this before in the list I started over with a clean $HOME, and I moved back the non-GNOME stuff (.ssh, .gnupg, .bash*, etc). But maybe it was overkill. Thanks for sharing. I will maybe try that tomorrow (late here). usermod -l ... ? ;-) S -- Mit freundlichen Grüßen / Best regards Randolph Maaßen
Re: [gentoo-user] E17 lock screen
On 12/27/2012 05:16 PM, Mick wrote: On Saturday 22 Dec 2012 01:29:57 Kevin Brandstatter wrote: So e17 just came out and ive been using for a bit. The only problem ive had with it is that i cant check the option to lock the screen on suspend. I don't think this is a problem on some of the other distributions so thought it could be a policy problem on gentoo. Curious if anyone else uses e17/has this problem and maybe a fix. or just for suggestions of where to look I can't select it here either, but I suspect that this may be because I do not use xscreenlock or equivalent. Have you tried posting either at the e17 or the enlightenm...@gentoo.org mailing lists? yes I first posted to the e17-users list. It was working for other people so i thought it might be distro specific, I emerged xscreensaver to see if that would fix it at all but no luck. I had this problem a while ago and i think it had something to do with polkit settings -Kevin signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan: On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote: Even Linus piped up at one point, sharply reminding Greg KH that even though udev was at one time Greg's 'baby', at this point udev serves only the wants of the few. link? -- #163933
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 02:06:27AM +0100, Volker Armin Hemmann wrote: Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan: On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote: Even Linus piped up at one point, sharply reminding Greg KH that even though udev was at one time Greg's 'baby', at this point udev serves only the wants of the few. link? Surf around here http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus%3D55168 -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] gconf - failed: not writable
trying to emerge: gnome-base/gconf-2.32.4 and I'm getting a strange error: Failed to emerge gnome-base/gconf-2.32.4, Log file: '/var/log/portage/gnome-base:gconf-2.32.4:20121228-021346.log' Jobs: 2 of 23 complete, 1 failedLoad avg: 1.05, 0.61, 0.41 * Package:gnome-base/gconf-2.32.4 * Repository: gentoo * Maintainer: gn...@gentoo.org * USE:amd64 elibc_glibc gtk introspection kernel_linux ldap policykit userland_GNU * FEATURES: sandbox ACCESS DENIED open_wr: /root/.gconf/.testing.writeability ACCESS DENIED unlink: /root/.gconf/.testing.writeability (gconftool-2:24669): GConf-WARNING **: None of the resolved addresses are writable; saving configuration settings will not be possible * Fixing OMF Makefiles ... [ ok ] * Disabling deprecation warnings ... [ ok ] * Running elibtoolize in: GConf-2.32.4/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.2.6 patch ... * Applying gconf-2.24.0-no-gconfd.patch ... [ ok ] * Applying gconf-2.28.0-entry-set-value-sigsegv.patch ... [ ok ] --- ACCESS VIOLATION SUMMARY --- LOG FILE /var/log/sandbox/sandbox-24640.log VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /root/.gconf/.testing.writeability A: /root/.gconf/.testing.writeability R: /root/.gconf/.testing.writeability C: /usr/bin/gconftool-2 --shutdown F: unlink S: deny P: /root/.gconf/.testing.writeability A: /root/.gconf/.testing.writeability R: /root/.gconf/.testing.writeability C: /usr/bin/gconftool-2 --shutdown -- Joseph
Re: [gentoo-user] gconf - failed: not writable
On Thu, Dec 27, 2012 at 6:16 PM, Joseph syscon...@gmail.com wrote: trying to emerge: gnome-base/gconf-2.32.4 and I'm getting a strange error: SNIP -- Joseph Saw the same thing here this morning, and have seen it a couple of times in the past. My strategy is to sync tomorrow and try again or mask the package if you need to move forward tonight. (California time, 6:21PM as I write this)
Re: [gentoo-user] gconf - failed: not writable
On 12/27/12 18:21, Mark Knecht wrote: On Thu, Dec 27, 2012 at 6:16 PM, Joseph syscon...@gmail.com wrote: trying to emerge: gnome-base/gconf-2.32.4 and I'm getting a strange error: SNIP -- Joseph Saw the same thing here this morning, and have seen it a couple of times in the past. My strategy is to sync tomorrow and try again or mask the package if you need to move forward tonight. (California time, 6:21PM as I write this) Looking at the package list: http://packages.gentoo.org/package/gnome-base/gconf?arches=fbsd gnome-base/gconf is not mark stable or testing at all, there is a blank space. gconf-2.32.4 was already installed on my system, emerge is trying to rebuild it only, but since it is not available it fails. -- Joseph
Re: [gentoo-user] gconf - failed: not writable
On 12/27/12 18:21, Mark Knecht wrote: On Thu, Dec 27, 2012 at 6:16 PM, Joseph syscon...@gmail.com wrote: trying to emerge: gnome-base/gconf-2.32.4 and I'm getting a strange error: SNIP -- Joseph Saw the same thing here this morning, and have seen it a couple of times in the past. My strategy is to sync tomorrow and try again or mask the package if you need to move forward tonight. (California time, 6:21PM as I write this) It is a bug: https://bugs.gentoo.org/show_bug.cgi?id=448952 -- Joseph
Re: [gentoo-user] gconf - failed: not writable
Yeah, bugs happen. Like I said, wait a day and try again.
Re: [gentoo-user] /dev/shm permissions drwxr-xr-x root:root ?
On Thu, Dec 27, 2012 at 01:49:01PM +0800, William Kenworthy wrote Do you have the fstab line: none /dev/shm tmpfs defaults 0 0 I had an ancient version, which I've been copying to new installs for years. It was... shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 I changed over to your line, and rebooted, but no difference. I finally did things the hard way in fstab... none /dev/shmtmpfs rw,noatime,noexec,nosuid,nodev 0 0 ...and in /etc/local.d/000.start I've added a chmod line... #!/bin/bash mount devpts chmod 1777 /dev/shm Note that on my system, defaults in fstab allows scripts to execute on /dev/shm, which is generally frowned on. noexec blocks that, notwithstanding the chmod 1777. Out of sheer curiousity, what happens when you create file /dev/shm/hello with 2 lines... #!/bin/bash echo Hello World ...and then you chmod 755 /dev/shm/hello /dev/shm/hello Does it execute or come back with permission denied? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On Thu, Dec 27, 2012 at 06:50:07PM -0500, Michael Orlitzky wrote Once you've upgraded, you should be able to add all of your old --state rules normally, albeit with a warning. The new iptables will translate them to conntrack rules, and you can `/etc/init.d/iptables save` the result. The upgrade just fails in a horrible way. Here's my revised Paranoia Plus ruleset. Any comments? Because I'm behind a NAT-ing ADSL router/modem, many of my rules rarely see hits. However, I do have a backup dialup connection in case of problems, so most of my rules don't specify the network interface. A couple of notes... * My little lan is 192.168.123.248/29 * I have a TV tuner box that comes up in the zero-config space, so I have to allow 169.254.0.0/16 * I dislike a certain button following me. # Generated by iptables-save v1.4.16.3 on Thu Dec 27 22:43:12 2012 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :DROP_LOG - [0:0] :FECESBOOK - [0:0] :ICMP_IN - [0:0] :PRIVATE - [0:0] :PRIVATE_LOG - [0:0] :TCP_IN - [0:0] :UDP_IN - [0:0] :UNSOLICITED - [0:0] [0:0] -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT [0:0] -A INPUT -s 169.254.0.0/16 -i eth0 -j ACCEPT [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK [0:0] -A INPUT -s 69.220.144.0/20 -j FECESBOOK [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK [0:0] -A INPUT -s 69.171.224.0/19 -j FECESBOOK [0:0] -A INPUT -s 200.58.112.0/20 -j FECESBOOK [0:0] -A INPUT -s 213.155.64.0/19 -j FECESBOOK [0:0] -A INPUT -p tcp -m tcp --sport 53 -j ACCEPT [0:0] -A INPUT -p udp -m udp --sport 53 -j ACCEPT [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -f -j LOG --log-prefix FRAGMENTS: --log-level 6 [0:0] -A INPUT -f -j DROP [0:0] -A INPUT -p tcp -j TCP_IN [0:0] -A INPUT -p udp -j UDP_IN [0:0] -A INPUT -p icmp -j ICMP_IN [0:0] -A INPUT -j LOG --log-prefix BAD_PROTOCOL: --log-level 6 [0:0] -A INPUT -j DROP [0:0] -A OUTPUT -d 192.168.123.248/29 -o eth0 -j ACCEPT [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 30 -j ACCEPT [0:0] -A OUTPUT -p tcp -m tcp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p tcp -m tcp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -j ACCEPT [0:0] -A DROP_LOG -j LOG --log-level 6 [0:0] -A DROP_LOG -j DROP [0:0] -A FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP [0:0] -A ICMP_IN -p icmp -m conntrack --ctstate NEW -j UNSOLICITED [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 0 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 3 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 4 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 11 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 12 -j PRIVATE [0:0] -A ICMP_IN -j LOG --log-prefix IN_BAD_ICMP: --log-level 6 [0:0] -A ICMP_IN -j DROP [0:0] -A PRIVATE -s 10.0.0.0/8 -j PRIVATE_LOG [0:0] -A PRIVATE -s 127.0.0.0/8 -j PRIVATE_LOG [0:0] -A PRIVATE -s 172.16.0.0/12 -j PRIVATE_LOG [0:0] -A PRIVATE -s 192.168.0.0/16 -j PRIVATE_LOG [0:0] -A PRIVATE -j ACCEPT [0:0] -A PRIVATE_LOG -j LOG --log-prefix IN_BAD_ADDR: --log-level 6 [0:0] -A PRIVATE_LOG -j DROP [0:0] -A TCP_IN -p tcp -m tcp --dport 0:1023 -j DROP_LOG [0:0] -A TCP_IN -p tcp -m tcp --dport 6000:6063 -j DROP_LOG [0:0] -A TCP_IN -p tcp -m tcp --sport 53 -j PRIVATE [0:0] -A TCP_IN -p tcp -m tcp --sport 80 -j PRIVATE [0:0] -A TCP_IN -p tcp -m conntrack --ctstate NEW -m tcp -j UNSOLICITED [0:0] -A TCP_IN -p tcp -j PRIVATE [0:0] -A UDP_IN -p udp -m udp --dport 0:1023 -j DROP_LOG [0:0] -A UDP_IN -p udp -m udp --dport 6000:6063 -j DROP_LOG [0:0] -A UDP_IN -p udp -m udp --sport 53 -j PRIVATE [0:0] -A UDP_IN -p udp -m udp --sport 80 -j PRIVATE [0:0] -A UDP_IN -p udp -m conntrack --ctstate NEW -j UNSOLICITED [0:0] -A UDP_IN -p udp -j PRIVATE [0:0] -A UNSOLICITED -j LOG --log-prefix UNSOLICITED: --log-level 6 [0:0] -A UNSOLICITED -j DROP COMMIT # Completed on Thu Dec 27 22:43:12 2012 -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] gconf - failed: not writable
On Thu, Dec 27, 2012 at 07:34:00PM -0700, Joseph wrote: Looking at the package list: http://packages.gentoo.org/package/gnome-base/gconf?arches=fbsd gnome-base/gconf is not mark stable or testing at all, there is a blank space. gconf-2.32.4 was already installed on my system, emerge is trying to rebuild it only, but since it is not available it fails. -- Joseph mingdao@workstation ~ $ eshowkw gnome-base/gconf Keywords for gnome-base/gconf: | | u | | a a p s | n | | l m h i m m p s p | u s | r | p d a p a 6 i p c 3 a x | s l | e | h 6 r p 6 8 p p 6 9 s r 8 | e o | p | a 4 m a 4 k s c 4 0 h c 6 | d t | o --+---+-+--- [I]2.32.4 | + + + o + o ~ + + o + + + | o 2 | gentoo 3.2.5 | ~ ~ ~ o ~ o ~ ~ ~ o ~ ~ ~ | o | gentoo -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. This is where you stumble. It's not a fix. It's a WONTFIX. It's a make a lot of noise so that something else gets fixed because this is outside of our domain and we're not going to be responsible for it as it wasnt our bug in the first place. And that something else happens to be the / and /usr split conflicting with the user programs. I understand that. I made that point myself; that the Gentoo dev moved udev into /usr to reduce the bug passing load on himself. If you give the squeaky wheel the grease - as in merge / and /usr - you apply the fix independently of udev, which was simply installed to the /usr prefix. THAT is a solution - one independent of udev and again, does not depend on initr*. You don't have to. That's one solution, but the cure is worse than the disease. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. Two things. First, I'm not saying that a spec should specify everything. I am saying, however, that there are specific cases that is within its domain to specify and that it should be specifying. And because those cases generate conflicts, the fact that they aren't is a bug. The spec also doesn't say anything about /usr/lib vs /usr/lib32 vs /usr/lib64, yet decisions about those can also cause conflicts. I suppose you'd argue that that's also a bug. I already gave you a pretty succinct definition of what I thought the treatment of /usr should be. And you quoted FHS on the subject, which was eerily similar to what I described. Now, further down, you actually raise specific issues. Let's focus on those. Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. So let's look at it deeply, since nobody else will. I'm game. This is the most detailed technical discussion of the problem anyone's cared to actually have, as far as I've been able to observe. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/2012 10:59 PM, Walter Dnes wrote: Here's my revised Paranoia Plus ruleset. Any comments? Because I'm behind a NAT-ing ADSL router/modem, many of my rules rarely see hits. However, I do have a backup dialup connection in case of problems, so most of my rules don't specify the network interface. A couple of notes... I did a bunch of inline comments below as I was trying to understand the rules. At the end I give the tl;dr, but maybe the inline comments are useful too. * My little lan is 192.168.123.248/29 * I have a TV tuner box that comes up in the zero-config space, so I have to allow 169.254.0.0/16 * I dislike a certain button following me. # Generated by iptables-save v1.4.16.3 on Thu Dec 27 22:43:12 2012 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] You can save yourself some complexity by allowing outbound traffic by default. I see that your INPUT policy is set to DROP, but you override this in a few places: at the end of all the chains, you jump to the PRIVATE table, which ends with a -j ACCEPT. So you'll accept anything that isn't rejected by a previous rule. I'd suggesting flipping that: get rid of the -j ACCEPT at the end of the private table, and allow unmatched traffic to be dropped. :DROP_LOG - [0:0] :FECESBOOK - [0:0] :ICMP_IN - [0:0] :PRIVATE - [0:0] :PRIVATE_LOG - [0:0] :TCP_IN - [0:0] :UDP_IN - [0:0] :UNSOLICITED - [0:0] [0:0] -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT Since you've self-proclaimed as paranoid, I don't feel bad suggesting that you choose which ports to allow incoming, even to the LAN. If somebody brings (or creates!) a compromised machine onto your LAN, they're going to be able to hit any ports that you've got open and available through the firewall. Not much you can do about that. But you might as well prevent them from reaching everything. If you expect to SSH from the LAN, sure, let that in. But if you're not serving e.g. web pages, you might as well block port 80 from the LAN. This allows you the freedom to play with apache without worrying about whether or not you've secured it. [0:0] -A INPUT -s 169.254.0.0/16 -i eth0 -j ACCEPT I don't know anything about zeroconf, not qualified to comment. [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK [0:0] -A INPUT -s 69.220.144.0/20 -j FECESBOOK [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK [0:0] -A INPUT -s 69.171.224.0/19 -j FECESBOOK [0:0] -A INPUT -s 200.58.112.0/20 -j FECESBOOK [0:0] -A INPUT -s 213.155.64.0/19 -j FECESBOOK [0:0] -A FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP Cute =) That final DROP is only needed since you -j PRIVATE (which defaults to ACCEPT) at the end of everything. [0:0] -A INPUT -p tcp -m tcp --sport 53 -j ACCEPT [0:0] -A INPUT -p udp -m udp --sport 53 -j ACCEPT Ok, in the INPUT chain you're accepting DNS traffic early. You do it again below, so I think the later one is redundant. [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -f -j LOG --log-prefix FRAGMENTS: --log-level 6 [0:0] -A INPUT -f -j DROP [0:0] -A INPUT -p tcp -j TCP_IN [0:0] -A INPUT -p udp -j UDP_IN [0:0] -A INPUT -p icmp -j ICMP_IN [0:0] -A INPUT -j LOG --log-prefix BAD_PROTOCOL: --log-level 6 [0:0] -A INPUT -j DROP DROP is redundant, since the INPUT policy is DROP. [0:0] -A OUTPUT -d 192.168.123.248/29 -o eth0 -j ACCEPT [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 30 -j ACCEPT [0:0] -A OUTPUT -p tcp -m tcp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p tcp -m tcp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -j ACCEPT Aha, you're overriding the OUTPUT policy of DROP here with an ACCEPT. You might as well set the policy to ACCEPT, and get rid of the trailing -j ACCEPT. Anything that is explicitly ACCEPTed above but not otherwise DROPped is also redundant, since traffic will be accepted by default if not dropped. I see that you want to log-before-drop specific traffic; that would still work with a policy of ACCEPT. You would add only those rules to the OUTPUT chain. [0:0] -A DROP_LOG -j LOG --log-level 6 [0:0] -A DROP_LOG -j DROP DROP would be redundant without the -j ACCEPT at the end of the PRIVATE TABLE. [0:0] -A ICMP_IN -p icmp -m conntrack --ctstate NEW -j UNSOLICITED [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 0 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 3 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 4 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 11 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 12 -j PRIVATE [0:0] -A ICMP_IN -j LOG --log-prefix IN_BAD_ICMP: --log-level 6 [0:0] -A ICMP_IN -j DROP DROP would be redundant without the -j ACCEPT at the end of the
Re: [gentoo-user] /dev/shm permissions drwxr-xr-x root:root ?
On 28/12/12 11:25, Walter Dnes wrote: chmod 755 /dev/shm/hello /dev/shm/hello as a user (not root) wdk@moriah /home/vm/qemu/mail $ vi /dev/shm/hello wdk@moriah /home/vm/qemu/mail $ chmod 755 /dev/shm/hello wdk@moriah /home/vm/qemu/mail $ /dev/shm/hello Hello World wdk@moriah /home/vm/qemu/mail $ worked fine. and moriah ~ # mount|grep shm none on /dev/shm type tmpfs (rw,relatime) moriah ~ # BillK
Re: [gentoo-user] IPTABLES syntax change?
I'm sure I made more than one typo, but the ALLOWED_ICMP below
definitely needs a dollar sign.
for ok_icmp in ALLOWED_ICMP; do
iptables -A ICMP_IN -p icmp --icmp-type ${ok_icmp} -j ACCEPT
done
[gentoo-user] php CURRENT_TIMESTAMP vs NOW()
I'm not a PHP programmer but I'll try to explain my problem. I've create table in my php database: DROP TABLE IF EXISTS visual_verify_code; CREATE TABLE visual_verify_code ( oscsid varchar(32) NOT NULL, code varchar(6) NOT NULL, dt TIMESTAMP(12) NOT NULL DEFAULT NOW(), PRIMARY KEY (oscsid) ); It worked OK, after few days I backup my database and try to restore it, but it keeps complaining on the dt: ERROR 1067 (42000) at line 38009: Invalid default value for 'dt' so the database is dropped but never restored. The backup data base contain: create table visual_verify_code ( oscsid varchar(32) not null , code varchar(6) not null , dt timestamp default 'CURRENT_TIMESTAMP' not null , PRIMARY KEY (oscsid) ); so the difference is: dt TIMESTAMP(12) NOT NULL DEFAULT NOW(), vs dt timestamp default 'CURRENT_TIMESTAMP' not null , If I change in backup database the line to: dt TIMESTAMP(12) NOT NULL DEFAULT NOW(), I can restore it without problems. Why is it doing it? In dt table structure the default has option: - None - As Defined: - NULL - CURRENT_TIMESTAMP If I change setting from CURRENT_TIMESTAMP to any of the above will it help restore it correctly? -- Joseph
Re: [gentoo-user] php CURRENT_TIMESTAMP vs NOW()
On 12/28/2012 01:44 AM, Joseph wrote: I'm not a PHP programmer but I'll try to explain my problem. I've create table in my php database: DROP TABLE IF EXISTS visual_verify_code; CREATE TABLE visual_verify_code ( oscsid varchar(32) NOT NULL, code varchar(6) NOT NULL, dt TIMESTAMP(12) NOT NULL DEFAULT NOW(), PRIMARY KEY (oscsid) ); Looks fine. It worked OK, after few days I backup my database and try to restore it, but it keeps complaining on the dt: ERROR 1067 (42000) at line 38009: Invalid default value for 'dt' so the database is dropped but never restored. The backup data base contain: create table visual_verify_code ( oscsid varchar(32) not null , code varchar(6) not null , dt timestamp default 'CURRENT_TIMESTAMP' not null , PRIMARY KEY (oscsid) ); CURRENT_TIMESTAMP shouldn't be quoted. How are you backing up the database?
Re: [gentoo-user] /dev/shm permissions drwxr-xr-x root:root ?
On Thu, Dec 27, 2012 at 10:25 PM, Walter Dnes waltd...@waltdnes.org wrote: On Thu, Dec 27, 2012 at 01:49:01PM +0800, William Kenworthy wrote Do you have the fstab line: none /dev/shm tmpfs defaults 0 0 I had an ancient version, which I've been copying to new installs for years. It was... shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 I changed over to your line, and rebooted, but no difference. I finally did things the hard way in fstab... Have you somehow disabled the localmount service? That fstab line should work fine.
Re: [gentoo-user] gnome 3.6 ... and related thoughts
Re 50DCE1AD.9060400@xunil.at50DCE1AD.9060400@xunil.atCADPrc829HM4216VAaPb3HSq4mcUT52JDpzfxAEpuT6W4ZFe_Ng@mail.gmail.com50dcc1bb.4080...@xunil.at, Randolph Maaßen said: Maybe interesting to read: http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ I think we had this before in the list Thank goodness for XFCE. I ditched Gnome at 3.0. Well, I was using XFCE even before that but still had gnome installed for other users of my system. Now, everyone uses XFCE. That's my own BOFH attitude right now. :) -- Keith -- -- ~ Keith Dart ke...@dartworks.biz public key: ID: 19017044 http://www.dartworks.biz/ =
Re: [gentoo-user] gnome 3.6 ... and related thoughts
Am 28.12.2012 01:02, schrieb Stefan G. Weichinger: I *liked* the old way ... is there any explanation why removing this improves things? How is it supposed to work now? That's the sane question to ask, unfortunately you won't get a real answer from the GNOME developers themselves. They are still happy for mistreating the desktop as a tablet and to continue alienating their loyal user base with that shitty piece of crap they call GNOME 3.X, praising themselves still that every remove of a beloved feature is a mile stone in terms of usability and not facing the reality. Also knowing better than the user himself what bells and whistles he needs to configure his computer and not has also a long tradition in GNOME. It is really no wonder, that quite some major distributions ditched GNOME 3.X vanilla either for their own homegrown stuff or MATE/Cinnamon. So it is really no wonder either, that GNOME 3.X ruined it for a large part of their former user base and they switched to other desktop environments.
