Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Discussing vdev from Devuan Project
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Feb 20, 2015 9:41 pm    Post subject: Reply with quote

judecn wrote:
I considered PAM before creating vdev. The reason I'm not using it is because it doesn't solve the problem adequately. PAM concerns itself with supporting multiple arbitrary ways to authenticate PAM-aware programs. Recall that I need a way to authenticate arbitrary processes without modifying them.

I could achieve my goals with some combination of PAM and existing tools (i.e. udev rules/mdev scripts) on a case-by-case basis, but I would be solving different instances of the same problem over and over again. vdev saves me the effort, and by simplifying the problem domain to only three parameters (X, Y, and P), it makes it much easier to reason about device file access control than trying to consider the (fundamentally undecidable) side-effects of combining existing tools in different ways to address each specific (X, Y, P) tuple.

I think our difference in opinions stem from my desire to do only what it necessary to enforce a certain class of access control policies, whereas you think that because what we have now is sufficient, no further work is needed in this space. However, I think we both agree that parsimony is an important principle to stick with in system design. What I have argued in my earlier posts is that there are very real cases where the difference between doing only what is necessary (i.e. hiding or unhiding a device node from a process based on some runtime-evaluated predicate) versus using any/all existing tools to build a sufficient solution is so large that I either end up creating something that's a vdev work-alike, or I end up having to solve different instances of the same problem from scratch. Thus, I currently believe vdev is the more parsimonious solution (but I could be convinced otherwise, if for example there already is a work-alike somewhere that I don't know about).

Can you not see why your argument makes no sense to me, given that in your opinion I think "what we have now is sufficient"?

Firstly I don't think no more work is needed: just that it is simple userland stuff, if you use the existing facilities properly (which requires knowing about them first.)

Secondly the design flaw, is the insistence that you need to do extra authentication, beyond what is already easily provided by the kernel. You made reference before to information you have which the kernel does not.

While that may be appropriate for some daemons, and I have no issue with vdev (or w/e) setting permissions on a newly created device node, changing permissions around after the event is prone to issues. And the question remains: why does that need to happen?

For the vast majority of desktops and laptops, it's completely irrelevant. My machines at home are not open to any and all on the internet, to login remotely. As usual a use-case that is way outside of scope, is instead used to justify what I consider idiotic changes across the board.

Parsimony in fact dictates that we don't reinvent what we already have, especially not when that is in-kernel, or widely established, with a solid history, especially by comparison with the other projects under discussion, like PAM.
steveL wrote:
WTF is portable about udev? And why does it need to be portable in the sense of providing the same API everywhere? That's the job of an OS-abstraction layer, not the job of an OS-specific device-node manager.

Quote:
Udev is not portable, and I consider this to be a limitation. Device file management is a solved problem, but every UNIX solves it differently without offering any fundamental improvements. This annoys me, since I use three different UNICES and would prefer to not have to figure out how to write the same device management rule three different ways.

You're mixing up the abstraction layer with the underlying OS-specific device-node manager.

It is not a limitation for the latter to be unportable: in fact there's no real way it can be truly portable, and still do the job effectively.
Quote:
You seem to be suggesting that it would be better to port the netlink socket class to each UNIX's OS abstraction layer. If so, this is overkill.

No, I'm saying stop muddling the two layers, and acting as if changes in the upper should dictate how the lower interfaces to the OS.

You're doing it again here, thinking of lower-level implementation when you were discussing a higher-level abstraction.
Quote:
The fact that udev uses netlink is an implementation detail that does not affect how it interfaces with other programs. Making vdev portable is just a matter of writing the appropriate OS-specific back-end "driver" that translates OS-specific device notifications into data structures that the rest of vdev understands.

IOW vdev is an upper-layer at this point, whereas above it is a lower layer that must be portable, or if not that's a "limitation" of the impl. Muddled thinking, afaic.

Better to do the work at this higher layer using the same approach as LADSPA. Yes, I mean split the two layers into separate projects, where the upper merely specifies the API (and thus ABI) that any shim to a lower-level must implement.

That would make your work on the design of the higher-level much more broadly useful, though ofc it cannot be done by you alone, or it would not gain traction with anyone who might have to implement it; better if they're involved with the agreed-upon design, or at least have the option to be.
Quote:
Quote:
There is nothing invariant about "an*arbitrary* predicate" evaluated at runtime.

Can I have vdev execute "sh -c dd if=/dev/urandom of=/dev/sda bs=1M" as part of its predicate? Sure. Will I actually do so? No. Will I include something like "For best results, ensure that your predicates have no externally-visible side-effects when evaluated and are guaranteed to run to completion" in the documentation? I guess I'll have to.

Well you could start by not using the word "invariant" since it isn't.
Quote:
Quote:
You're conflating LTSP type deployments, with device-node marking, as if hype about the second necessarily implies hype about the former; then criticising me for using the term hype about the second, and acting as if I'm suddenly some sort of luddite. Don't do that.

You're not a luddite, and I never said or even thought you were. I was pointing out that I find it odd to characterize a widely-used and proven computer multiplexing mechanism as hype, since "hype" implies that lots of people are excited about it, but no one is using it for anything serious.

IOW I'm a luddite, or my thinking is mistaken in some other way, when you are in fact making the same conceptual error I asked you to refrain from.
Quote:
I understand that the greater Linux community is perhaps more excited about it than it needs to be, but the real-world cases I was thinking of are the large-scale multi-seat deployments in Brazil and Macedonia, used for giving school children access to computers.

Which are done using projects like LTSP, and not with mere device-node marking, which was my precise point.

This (sharing a laptop via another USB hub) is another use-case that is a solution looking for a problem, likely arising because someone realised "hey we can mark device nodes according to the hub they're on"; not because users were clamouring for the facility, and people got together to think out the best approach. That already happened decades ago, which is why there are "real-world cases" for you to talk about; none of which are examples of the technology you're espousing.
Quote:
Quote:
But it doesn't preclude bind-mounting the specific nodes you want to expose.

Maybe you meant "symlink" or "hardlink", since I'm pretty sure you can't bind-mount a file ;).

Actually, I'm pretty sure you can. Whether you actually want to is another matter.
Quote:
Besides, it doesn't solve the problem of having the device nodes appear in each container's /dev without necessarily coupling the policy logic in the udev rules/mdev scripts to my container policies.

Whut? If I want containers, I configure container policies. What could be easier to get my head round?

More importantly, if I'm not using containers, I should not even have to think about them, let alone rebuild all my software so someone else can use them at a completely different installation.
Quote:
At least with vdev's approach, the coupling between device node management policy and container setup policy is necessarily factored out into a predicate.

I wish you'd stop going on about predicates as if they're unique selling-points of vdev. (A predicate is just a conditional, for anyone who's not familiar with the term.) It's about as useful as banging on about "invariants" that are not in fact invariant.
Quote:
With udev/mdev, I would instead need to create an "inner platform" for them to act on container policies without hard-wiring their behaviors.

Well I'd rather have containers of all forms handled cleanly in one configuration format, related to the init-manager; iow not at the udev level. Though support for it from vdev or w/e may be useful, I can't really see a great need right now. It's one for the users to decide, given use-cases that actually need dynamic device-node management, which aren't already vms.

In any event, you can bind-mount file nodes, to my knowledge, but this ties into a newns command along the lines of nspawn (ie a wrapper for clone(2) in the main, though se_linux needs some extra stuff.) In some cases (like console, zero, null..) it's easier just to make the nodes, and where that works we should use it; in others you want the external node bound in, and most cases you don't want any connection.

So overall it sounds like something where we'd have a set of defaults, added to by the service in question if there is one related to this instance, and configured by the user just like anything else; in plaintext.

I don't see the point of involving udev at all, atm, since where that matters people would usually use a vm in any case. Configuring that as part of the init-manager setup is again nothing to do with udev (or any replacement) since by definition it is a new OS instance. The most that might be needed is some OS-specific smarts when running under virtualisation, and like I said that's got nothing to do with a "portable abstraction", though it does relate to openrc in that some services cannot run under vms, as others cannot run in a jail, according to the configuration in the runscript.

Feel free to show me I'm wrong ofc.
Quote:
What I am arguing is that there is a general formulation of the problems I'm trying to solve, and by designing vdev to reduce each instance of the problem to a few parameters, I can solve each instance of the problem and reason about its correctness much more readily than creating one-off point solutions to each instance.

Yet we still haven't got a clear idea of what those problems are, or I haven't, beyond "reinventing udev portably". There are design problems when every app cares about device nodes coming and going, or has to be recompiled just because we're using a different "abstraction".

I am at a loss as to why anything beyond a DE or a file-manager, typically specific to a DE, would care. Until that is explained adequately, with use-cases that really justify it, then I'll continue to insist that it's not been thought-through.

And no dd or some other program accessing a disk at low-level, doesn't need to care either; an EIO or some other code is sufficient.
Quote:
That makes no sense at all to me. "You can use my webcam to spy on me so long as I haven't logged in, or if I log out, or you manage to log me out via one of the many attack surfaces we've been busily adding."

Quote:
More like, "When no one is using my home computer, I want to use its webcam to watch the door to my house" or "When no one is using my office computer between these hours at night, I want to watch and listen for intruders" or "When no one is using my office computer at all, I want to run OpenCL workloads on its GPU."

Let's go back to what you wrote, as I'm having trouble relating the above to anything in particular:
Quote:
Many users have an account on the same machine, but at most one person can log in locally. Any of them can ssh in remotely. If a user is logged in locally, the other users *cannot* be allowed to access the input devices, video devices, or removable storage devices, since the local user must have exclusive read/write access for security purposes (moreover, any programs that have opened these files must be terminated before the local user logs in). Also, remote users should not be allowed to learn information that would allow them to infer what the local user is doing--for example, they should not even see the appearance of a device file corresponding to a removable drive. At the same time, this restriction should only apply while someone is logged in locally--for example, barring a local login, remote users should be able to use the GPU for OpenCL programs, and access hardware sensors (i.e. the webcams, the microphone, the ambient temperature, etc.) to check up on the room the computer resides in (but these should be locked out when someone has logged in locally, for privacy).
which sounds like one specific configuration you would like. Not the only setup in the world, that should apply to everyone, correct?
As atm you seem to be presenting it as so. Lots of "must" and "should not" as if this were a standards document, and not your idea of how you'd like your machine to run.

As for only one person can login locally, isn't that handled already by the DM for you? Only one active login on the display in question.

Or are you trying to also lock it down so no-one else can login to the console when you are logged into the DM? That would be strange.

Personally I'm happy with group permissions for the above. I trust the kernel much more than I trust random userland programs, of questionable design.

I certainly would not be happy leaving the decision as to who can access my webcam to the vagaries of the "policy abstraction" du-jour.

Especially not if that abstraction isn't an abstraction, but instead a codification of somebody else's idea of how things should be. That's half the problem with systemdbug (that and the insanity of its lead.)
Quote:
Quote:
Oh dear, no. You haven't understood what I meant at all. Do you really believe hal for example, wasn't already a second system when it was pushed too early, in 0.x stage? You must have seen the modern trend toward TDD which is basically reiterating the methodology people have been using for decades. People have been planning "to throw one away" for decades, and the problem is that means they're foisting their second-systems on us instead. After all, someone else can patch it up later, right?

What does TDD have to do with hal, and what does hal have to do with vdev? hal operates in a different problem domain than vdev, and vdev's scope is a *lot* smaller.

My point was about second-system effect, which is an overall software development point, and not about any specific project, except in that many of the projects discussed display exactly that. An overweening sense of grandeur, rather than the humility that typifies both first and third systems.
Quote:
Quote:
The problem is so much of what they're doing is totally unnecessary.

Agreed. They failed in part because they didn't understand the problem(s) they were trying to solve well enough, and in part because they had a tendancy to over-engineer their solutions (making them inflexible).

Well, sorry but atm I'm getting the same impression from your ideas. You don't appear to have questioned the actual use-cases, rather just got excited about the prospect of solving these problems that someone else has stipulated, in a "generic" manner.

And no offence, but conditions are hardly revolutionary, whatever label you put on them.
Quote:
Quote:
Why not just tie into things like AIDE instead of reinventing the wheel? If the user has it then they're taking it seriously; if not then don't provide a false lullaby. Down that route lies importing unreviewed crypto from my brother, as nepotism trumps technical merit in the Brave Nub World-2.0.. ;)

Because the problem you're referring to is not related to intrusion detection; it's related to identifying a particular process that's attempting to access a device file.

Oh come on; an IDS keeps the csums/hashes for every command that can be run. If you're not doing it properly, then why bother with sha256 at all? It's just a false sense of security that sounds good, afaic.

Good one with making it C-only and tightening the linkage to /lib.
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Mon Mar 09, 2015 6:39 pm    Post subject: Reply with quote

I sense a lot of hostility and condescension in your replies, Steve.

I welcome any and all feedback and discussion that leads to the design and implementation of a better device manager, since that's what I'm after (be it one of my own making, or some other existing program). I'm not emotionally invested in vdev, and will gladly throw out or rewrite substantially what I have now if a fundamentally better approach can be found. You can check vdev's commit history to verify that I'm acting in good faith on this--the hotplug manager vdevd and libvdev (the parts that have to run early during boot) now only depend on libraries in /lib, vdev's dependency libpstat no longer requires libssl, and the equivocating filesystem vdevfs is now a wholly separate program that is built, installed, and run independently of vdevd. I'm currently working on allowing vdevfs to be mounted on top of a populated /dev, so users will have the option of using it alongside whatever agent creates device files without having to mount it at boot time (as is the case now).

What I do not welcome, and will no longer entertain, is feedback that assumes bad faith. It's possible have a conversation about the design and implementation of device managers without resorting to thinly-veiled insults. I've met you half-way on this; I expect you to extend the same courtesy if you want to continue this conversation.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Mar 10, 2015 8:54 am    Post subject: Reply with quote

judecn wrote:
I sense a lot of hostility and condescension in your replies, Steve.

You're reading in tone that is not intended then, a common problem when native speakers converse via text.

I haven't insulted you at all: I've actually complimented you by presuming you can deal with direct info, which I think you can.

I do tend to get somewhat Germanic in my approach when dealing with technical issues, and ignore social niceties; ime most people who are technically-focussed do the same, when we're chatting about the actual code or w/e.

I'm sorry if that has come across as rude; it sincerely was not my intent.

Like I said, I'm just discussing a technical design, in the same way I'd discuss any other piece of work; which means being able to call something borked, or crap even if I need to. More often it's crap I wrote, so I don't tend to be anything other than dismissive of something I think is wrong (because I usually need to junk it immediately, and discussing how it was wrong, and why I made that mistake isn't so cogent to getting the job done, especially in relation to others.)

It would be a bad idea to attach that meaning to anything other than what it is meant for.

For my part I ascribe to the fundamental rule of Communications Studies (as I studied it, anyhow); true communication only happens between equals. There's no condescension on my part, certainly not in terms of people.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2280
Location: Adendorf, Germany

PostPosted: Tue Mar 10, 2015 12:26 pm    Post subject: Reply with quote

steveL wrote:
I won't use it at all if it's in C++. Period.
Why?
Actually you can pump any C file through any C++ compiler and see, whether your C is good or not. C++ compilers are more strict than C compilers. Both by design of course. If it doesn't get compiled by a C++ compiler, a second look might be a good idea. (not necessarily of course.)

C++ does not mean you have to go all object oriented. It isn't smalltalk or java. But it allows you to cherrypick some fine stuff you will never see in C, but that *will* make your live easier. For instance: Constructors and Destructors for structs. Which allow RAII. Operator overloading for structs. Which makes copying or comparing struct data a piece of cake while in plain C... Or having function templates that instantiate on actual usage. In C you have to write an extra function (often with a crapload of code duplication) for each scenario and they all need unique names, too.

However, I wouldn't use the std containers. Not for such a system. That's one part I would leave as close to the C-Core as possible. I have never witnessed a situation where a singly or doubly linked list wouldn't've been enough unless you have to store a huge amount of key-value-pairs. Then a map or hash is far better (and offers a lot better performance) of course.

It boils down to this: You can do everything in C++ you can do in C and in most cases you can do it faster, more secure and easier. But there is a lot of stuff you can do in C++ that are either very difficult to achieve in C or not possible at all.
However: I am completely aware that there are too many C++ programmers out there creating overly large constructs for every tiny problem. In most cases I've seen in the last 20 years, those were simply people who didn't learn the C-core enough (or not at all). But then, this is not the fault of C++ as a language. It's theirs.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Mar 10, 2015 6:54 pm    Post subject: Reply with quote

steveL wrote:
I won't use it at all if it's in C++. Period.

Yamakuzure wrote:
Why?

We've had this discussion before, so I don't see the point in deflecting this thread into another "C++ is great" vs: "No, it's not, it's crap" argument. Neither of us is going to change the other person's opinion, nor is that argument on-topic for this thread.

For system stuff, the C++ ever-changing ABI-per-compiler is an issue, apart from the discussion about the language itself.

I'm just stating that so one of my reasons (not about the horrible lack of language-design) is clear. Please don't argue with me about it. No doubt you'll want to show how that's untrue/can be worked round/isn't an issue on a "modern" system with x, y, z caveats/pick something, and by all means express your opinion if you must (succinctly, preferably from my side;)

Just don't seek to persuade me that my reasons, because they don't matter to you, should not matter to me either. That'll only take us down a rabbit-hole neither of us has really got the time for, no-one else will care about, and that will lead us back to the same place we're at now, only more stressed-out.

Hope that's okay.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Jun 22, 2015 5:39 pm    Post subject: Reply with quote

steveL wrote:
I do tend to get somewhat Germanic in my approach when dealing with technical issues, and ignore social niceties; ime most people who are technically-focussed do the same, when we're chatting about the actual code or w/e.

I'm sorry if that has come across as rude; it sincerely was not my intent.

Mea culpa.

Discussing it with another user in private, I realise I've been ignoring social cues in a way I wouldn't have 5, or even 3, years ago.

It is just talk about code, but that doesn't mean it can't be pleasant, so my apologies for making it less so.

Regards,
steveL.
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Tue Jun 23, 2015 5:39 pm    Post subject: Reply with quote

judecn wrote:
...openssl...sha256...


Just a suggestion: How about using the kernel? It is the most reliable thing we have.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/crypto/api-intro.txt

Code:

Here's an example of how to use the API:

   #include <linux/crypto.h>
   #include <linux/err.h>
   #include <linux/scatterlist.h>
   
   struct scatterlist sg[2];
   char result[128];
   struct crypto_hash *tfm;
   struct hash_desc desc;
   
   tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
   if (IS_ERR(tfm))
      fail();
      
   /* ... set up the scatterlists ... */

   desc.tfm = tfm;
   desc.flags = 0;
   
   if (crypto_hash_digest(&desc, sg, 2, result))
      fail();
   
   crypto_free_hash(tfm);


EDIT:
https://lwn.net/Articles/410536/
http://events.linuxfoundation.org/sites/events/files/slides/lcj-2014-crypto-user.pdf

Edit2:
Code:

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <linux/if_alg.h>
#include <linux/socket.h>

#include <stdlib.h>

#define SHA256_DIGEST_SZ 32

int main(void)
{
   struct sockaddr_alg sa = {
      .salg_family = AF_ALG,
      .salg_type = "hash",
      .salg_name = "sha256"
   };
   unsigned char digest[SHA256_DIGEST_SZ];
   char *input = "Hello World!";
   int bytes_to_write = strlen(input);
   
   int i, sockfd, fd, ret;

   sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
   if (bind(sockfd, (struct sockaddr *)&sa, sizeof(sa)) == -1) {
      perror("bind");
      exit(EXIT_FAILURE);
   }
   
   fd = accept(sockfd, NULL, 0);
   if (fd < 0) {
      perror("accept");
      exit(EXIT_FAILURE);
   }
   
   int pos = 0;
   while (pos < bytes_to_write) {
      int wrote = write(fd, input+pos, bytes_to_write-pos);
      if (wrote < 0) {
         perror("write");
         exit(EXIT_FAILURE);
      }
      pos += wrote;
   }

   pos = 0;
   while (pos < SHA256_DIGEST_SZ) {
      int bytes = read(fd, digest+pos, SHA256_DIGEST_SZ-pos);
      if (bytes < 0) {
         perror("read");
         exit(EXIT_FAILURE);      
      }
      pos += bytes;
   }

   close(fd);
   close(sockfd);
   for (i = 0; i < SHA256_DIGEST_SZ; i++)
      printf("%02x", digest[i]);
   printf("\n");
   return 0;
}


sha256 hash with AF_ALG from the kernel.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Jul 29, 2015 11:36 am    Post subject: Reply with quote

Just to clear up this part:
steveL wrote:
Mea culpa.

Discussing it with another user in private, I realise I've been ignoring social cues in a way I wouldn't have 5, or even 3, years ago.

It is just talk about code, but that doesn't mean it can't be pleasant, so my apologies for making it less so.

I spoke with jude via pm, and it's sorted (a while back.)

Won't quote pm as that would be bad form, but would like to get back to the interesting discussion, raised here by Ottre in his wonderful Distributions using eudev thread.
Jude responded here and here in response to Christoph Lohmann who seems somewhat annoying.

Reading the intro to vdev, it seems all about the highest-level layer, though if we check the other url jude mentions, it seems like the possibility to use just the two bottom-layers for udev is open:
judecn wrote:
First, there's vdevd (code is in vdevd/ and libvdev/, hardware database is in hwdb/, and recommended configuration, initscript, and initramfs scripts are in example/). When used with its recommended configuration, vdevd's goal is to be a udev work-alike. Specifically, vdevd generates a /dev tree equivalent to the one generated by udev, sets persistent network interface names, and generates enough of the /run/udev/ tree for udev client programs to continue working without modification.

Second, there's libudev-compat (code is in libudev-compat/). Libudev-compat's goals are two-fold. First, it strives to be an API- and ABI-compatible replacement for libudev, but without requiring a device manager to be installed (i.e. instead of opening a netlink socket to udev, it watches a directory into which some other program will put device events encoded as text files). This is by far the most common use-case. It's other goal is to allow the admin to manipulate and namespace device event queues on a per-process basis. This is specifically meant to help libudev-dependent programs run in containers without needing a device manager or direct access to /dev--the user can simply link the container's device event directory into a canonical place in the root context where device events will get written.

Third, there's vdevfs (whose code is under fs/). You probably don't need vdevfs if all you need is a udev/libudev replacement. Its goal is to enforce a per-process view of /dev, by allowing the admin to control which device files and inode metadata a given process will "see" on stat(2) and readdir(3). With the proper configuration and scripts (HUGE weasel words right there), an admin can use vdevfs to do ConsoleKit-like and logind-like things.

@judecn: The question I have is whether vdevd and libudev-compat are enough to support the Xorg udev config backend raised by Natanael Copa?
I'm guessing you're running xorg with vdev on your machine, so presumably it is.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Jul 29, 2015 11:39 am    Post subject: Reply with quote

schorsch_76 wrote:
Just a suggestion: How about using the kernel? It is the most reliable thing we have.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/crypto/api-intro.txt

Yeah that makes sense; the crypto API looks perfect for general usage.
Quote:
sha256 hash with AF_ALG from the kernel.

Heh that looks mad ;-) but useful if jude wants to daemonize the digest of path -> hash, eg to cache the values where inode mtime remains same.
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Wed Jul 29, 2015 2:12 pm    Post subject: Reply with quote

In fact my abouve code hat a issue. Sending bigger files through the socket i got the wront sha sum because it needs to be sent continious.

The most important change is:
Code:
int sent = send(fd, buffer.get()+pos, bytes_read-pos, MSG_MORE);


Here i explained a little about it.
https://www.schorsch-tech.de/doku.php?id=linux:kernel-hash-sha256

Code:

#include <unistd.h>
#include <string.h> // memcpy
#include <sys/socket.h>
#include <sys/sendfile.h>
#include <linux/if_alg.h>
#include <linux/socket.h>
 
#include <array>
#include <memory>
 
using sha256_t = std::array<unsigned char, 32>;
 
sha256_t sha256sum(int in, size_t buffer_size = 2048)
{
   std::unique_ptr<char> buffer(new char[buffer_size]);
 
   sha256_t digest;
 
   struct sockaddr_alg sa;
   sa.salg_family = AF_ALG;
   memcpy(sa.salg_type, "hash", 5);
   memcpy(sa.salg_name, "sha256", 7);
 
   int i, sockfd, fd;
 
   sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
   if (bind(sockfd, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
      perror("bind");
      exit(EXIT_FAILURE);
   }
 
   fd = accept(sockfd, NULL, 0);
   if (fd < 0) {
      perror("accept");
      exit(EXIT_FAILURE);
   }
 
   // "pipe" the in fd to the hash algorithm
   int pos;
   int bytes_read;
   while ((bytes_read = read(in, buffer.get(), buffer_size)) > 0)
   {
      pos = 0;
      while (pos < bytes_read)
      {
         int sent = send(fd, buffer.get()+pos, bytes_read-pos, MSG_MORE);
         if (sent < 0)
         {
            perror("send");
            exit(EXIT_FAILURE);
         }
         pos += wrote;
      }
   }
   send(fd, nullptr, 0, 0); // "flush" the hash
 
   pos = 0;
   while (pos < sizeof(sha256_t))
   {
      int bytes = read(fd, digest.data()+pos, sizeof(sha256_t)-pos);
      if (bytes < 0) {
         perror("read");
         exit(EXIT_FAILURE);      
      }
      pos += bytes;
   }
   close(fd);
   close(sockfd);
 
   return digest;
}
 
int main(void)
{
   sha256_t digest = sha256sum(STDIN_FILENO);
 
   for (size_t i = 0; i < sizeof(sha256_t); i++) {
      printf("%02x",digest[i]);
   }
   printf("\n");
   return 0;
}


Yes, this is c++11 but can be easily ported to C.
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://github.com/schorsch1976/portage
git clone https://github.com/schorsch1976/portage
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Thu Jul 30, 2015 3:14 pm    Post subject: Reply with quote

Hi Steve,

steveL wrote:
...but would like to get back to the interesting discussion, raised here by Ottre in his wonderful Distributions using eudev thread.
Jude responded here and here in response to Christoph Lohmann who seems somewhat annoying.

Reading the intro to vdev, it seems all about the highest-level layer, though if we check the other url jude mentions, it seems like the possibility to use just the two bottom-layers for udev is open:
judecn wrote:
First, there's vdevd (code is in vdevd/ and libvdev/, hardware database is in hwdb/, and recommended configuration, initscript, and initramfs scripts are in example/). When used with its recommended configuration, vdevd's goal is to be a udev work-alike. Specifically, vdevd generates a /dev tree equivalent to the one generated by udev, sets persistent network interface names, and generates enough of the /run/udev/ tree for udev client programs to continue working without modification.

Second, there's libudev-compat (code is in libudev-compat/). Libudev-compat's goals are two-fold. First, it strives to be an API- and ABI-compatible replacement for libudev, but without requiring a device manager to be installed (i.e. instead of opening a netlink socket to udev, it watches a directory into which some other program will put device events encoded as text files). This is by far the most common use-case. It's other goal is to allow the admin to manipulate and namespace device event queues on a per-process basis. This is specifically meant to help libudev-dependent programs run in containers without needing a device manager or direct access to /dev--the user can simply link the container's device event directory into a canonical place in the root context where device events will get written.

Third, there's vdevfs (whose code is under fs/). You probably don't need vdevfs if all you need is a udev/libudev replacement. Its goal is to enforce a per-process view of /dev, by allowing the admin to control which device files and inode metadata a given process will "see" on stat(2) and readdir(3). With the proper configuration and scripts (HUGE weasel words right there), an admin can use vdevfs to do ConsoleKit-like and logind-like things.

@judecn: The question I have is whether vdevd and libudev-compat are enough to support the Xorg udev config backend raised by Natanael Copa?
I'm guessing you're running xorg with vdev on your machine, so presumably it is.


You are correct--vdevfs is wholly optional and not necessary if all you want is a udev replacement. Vdevd, vdevfs, and libudev-compat have no dependencies on one another--you can use whatever combination of them you want :). Also, vdevd's helper scripts and auxiliary programs (not vdevd itself) are responsible for generating a udev-compatible /dev. They are somewhat decoupled from vdevd by design, in case the user wanted to use a different device manager. For example, it should be possible to create an mdev-script-to-vdev-script wrapper that would let you use vdevd's scripts with mdev, and still end up generating the same /dev and device metadata for libudev-compat.

I'm still testing the hotplug logic in its corner cases, but so far it seems to work. In fact, some other users in the Devuan community have told me that they're already using vdevd and libudev-compat with a udev-enabled X.org without problems.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Aug 01, 2015 3:59 pm    Post subject: Reply with quote

judecn wrote:
You are correct--vdevfs is wholly optional and not necessary if all you want is a udev replacement. Vdevd, vdevfs, and libudev-compat have no dependencies on one another--you can use whatever combination of them you want :).

Good, good :-)
Quote:
Also, vdevd's helper scripts and auxiliary programs (not vdevd itself) are responsible for generating a udev-compatible /dev. They are somewhat decoupled from vdevd by design, in case the user wanted to use a different device manager. For example, it should be possible to create an mdev-script-to-vdev-script wrapper that would let you use vdevd's scripts with mdev, and still end up generating the same /dev and device metadata for libudev-compat.

I don't understand; if "the user wanted to use a different device manager" surely they would be using it (eg: mdev), and not vdevd; or do you mean the other way round, using mdev scripts with vdevd (which "mdev-script-to-vdev-script wrapper" would imply)?
Quote:
I'm still testing the hotplug logic in its corner cases, but so far it seems to work. In fact, some other users in the Devuan community have told me that they're already using vdevd and libudev-compat with a udev-enabled X.org without problems.

Excellent, that's just what I wanted to hear. I think you should declare that loudly on that alpine list, if you haven't already.

One thing to bear in mind is pointed out by suckless (thanks again to Ottre), viz:
Quote:
libudev will be orphaned
With the advent of udevd there was a compatibility to its complexity called libudev. X11 uses it to query the changing devices. And of course make it a non-independent API in systemd. Why? You can guess why: Defeating the infidels.

So I think there's a real case for simply writing a variant of the config backend for vdev (C-only ofc;) or indeed any other device manager, so that users are never dependent on the whims of the ever-changing moods^W ABI of systemdiots.
Not sure what the eudev bods are going to do wrt that change.

Oh, if you get a moment, would be curious to hear your thoughts on the "ubus" thread. Cheers.
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Sun Aug 02, 2015 10:22 pm    Post subject: Reply with quote

Hi Steve,

steveL wrote:

I don't understand; if "the user wanted to use a different device manager" surely they would be using it (eg: mdev), and not vdevd; or do you mean the other way round, using mdev scripts with vdevd (which "mdev-script-to-vdev-script wrapper" would imply)?


Some of the Alpine and Suckless developers have expressed interest in using vdevd's helper scripts in conjunction with nlmon and mdev. I was trying to point out that this can be done by creating a wrapper script for mdev that would let it invoke the appropriate vdevd script (e.g. the wrapper would translate mdev's environment variables into vdev's).

steveL wrote:

Quote:
I'm still testing the hotplug logic in its corner cases, but so far it seems to work. In fact, some other users in the Devuan community have told me that they're already using vdevd and libudev-compat with a udev-enabled X.org without problems.

Excellent, that's just what I wanted to hear. I think you should declare that loudly on that alpine list, if you haven't already.


They know :). Even the Suckless developers expressed interest in re-using parts of vdevd with their in-house device manager in order to make this available for their distro.

steveL wrote:

One thing to bear in mind is pointed out by suckless (thanks again to Ottre), viz:
Quote:
libudev will be orphaned
With the advent of udevd there was a compatibility to its complexity called libudev. X11 uses it to query the changing devices. And of course make it a non-independent API in systemd. Why? You can guess why: Defeating the infidels.

So I think there's a real case for simply writing a variant of the config backend for vdev (C-only ofc;) or indeed any other device manager, so that users are never dependent on the whims of the ever-changing moods^W ABI of systemdiots.
Not sure what the eudev bods are going to do wrt that change.


That's what libudev-compat is trying to address. It's an API- and ABI-compatible libudev alternative that receives device events as text files written to a directory, instead of as packets on a netlink socket (meaning that any sufficiently-privileged process can generate and send device events). This is why libudev-compat doesn't depend with vdevd; to send device events, vdevd simply runs a helper script that writes the requisite device metadata to a file and links it into each libudev-compat process's directory.

I'm not terribly worried about libudev API breakage at this point. It's been in use for ~13 years now, and there are a *ton* of libudev-reliant programs out there. The libudev maintainers would be shooting themselves in the foot if they decided to break it now.

steveL wrote:
Oh, if you get a moment, would be curious to hear your thoughts on the "ubus" thread. Cheers.

Replied :). https://forums.gentoo.org/viewtopic-p-7791178.html#7791178
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Aug 13, 2015 11:52 am    Post subject: Reply with quote

judecn wrote:
Some of the Alpine and Suckless developers have expressed interest in using vdevd's helper scripts in conjunction with nlmon and mdev. I was trying to point out that this can be done by creating a wrapper script for mdev that would let it invoke the appropriate vdevd script (e.g. the wrapper would translate mdev's environment variables into vdev's).

Ah OK, now I get it ;)

That's the scripts in example/actions I take it? Or those are specific to vdev, since they require interpretation of the match etc?
Quote:
libudev-compat is .. an API- and ABI-compatible libudev alternative that receives device events as text files written to a directory, instead of as packets on a netlink socket (meaning that any sufficiently-privileged process can generate and send device events). This is why libudev-compat doesn't depend on vdevd; to send device events, vdevd simply runs a helper script that writes the requisite device metadata to a file and links it into each libudev-compat process's directory.

OK, yeah I've seen refs to /dev/metadata/udev/events though "each" implies N, presumably for jails and virtual machines?
Quote:
I'm not terribly worried about libudev API breakage at this point. It's been in use for ~13 years now, and there are a *ton* of libudev-reliant programs out there. The libudev maintainers would be shooting themselves in the foot if they decided to break it now.

Well I wouldn't put it past them to try the usual shenanigans, ie: rewrite to an internal "systemdiot" namespace, and provide a shim compatibility library for a while, with some specious nonsense about how everyone needs to get with the times, and it's only "supported" for a while. Anyone who doesn't will have their package labelled "bit-rot".
OFC none of this would work without some sort of implicit threat that you're not going to be supported on RHEL in the future, so it's not a technical argument, more a sociopolitical one. The end-result we've all seen with Microsoft.

But I agree that the compat lib is going to be useful for ages, given what you say about all the ABI-dependant binaries already distributed.

Going back to the interesting stuff, I took a look at the sound-audio action as an example:
Code:
[vdev-action]
event=add
path=^audio$
OS_SUBSYSTEM=sound
command=test -f "$VDEV_MOUNTPOINT/$VDEV_PATH" || (/bin/mknod "$VDEV_MOUNTPOINT/$VDEV_PATH" c $VDEV_MAJOR $VDEV_MINOR && exit $?); exit 0

It seems to me this should be a default, built-in, given no override from admin, ie to mknod the device node on add, if it doesn't exist. TBH I can't see why you wouldn't do that in any event.

Anyhow, you can tidy up the shell and avoid the fork implied by the subshell:
Code:
command=test -e "$VDEV_MOUNTPOINT/$VDEV_PATH" || /bin/mknod "$VDEV_MOUNTPOINT/$VDEV_PATH" c "$VDEV_MAJOR" "$VDEV_MINOR"; exit 0

-e is a quicker test than -f|d etc; it just needs access(F_OK), the others need a stat() or lstat() implying inode fetch.

If you were trying to use the subshell to return an error to the caller, based on exit status of mknod, then you'd keep it much simpler:
Code:
command=test -e "$VDEV_MOUNTPOINT/$VDEV_PATH" || /bin/mknod "$VDEV_MOUNTPOINT/$VDEV_PATH" c "$VDEV_MAJOR" "$VDEV_MINOR"

The subshell wouldn't have done that; it'd have just returned the exit status to the script, which would have happened anyway. In general, you'd use { braces; } to compound without subshell; note you'd need a trailing ';' after '}' to continue on same line, if no other terminator ('|' or '&') after it. However that isn't needed here.

Again though, it seems to me that should be done on add anyhow, from C; though I can understand why it might be useful for a fallback, eg with other device-managers, actions seem to require interpretation for match on add etc.
Back to top
View user's profile Send private message
augustin
Guru
Guru


Joined: 23 Feb 2015
Posts: 318

PostPosted: Fri Aug 28, 2015 3:07 pm    Post subject: Reply with quote

I am late to the party.
I'm just discovering vdev.

Admittedly, I am not very knowledgeable in this domain (euphemism/understatement), but reading the documents on the vdev web site, I am very pleased by the design goals and motivation.
Also, I am very impressed by Jude's constructive attitude in this thread, his receptiveness to comments here. Thank you very much for your contributions!

The web site does not say how stable the program is, whether it's ready for production use.
Also,
Code:
 emerge -s vdev
does not appear to return anything relevant.

I am looking forward to more freedom and more choice and better quality in the linux ecosystem.

Thanks.
Back to top
View user's profile Send private message
augustin
Guru
Guru


Joined: 23 Feb 2015
Posts: 318

PostPosted: Fri Aug 28, 2015 4:02 pm    Post subject: Reply with quote

How to test on Gentoo?
https://github.com/jcnelson/vdev/issues/47

I may have missed it, but I didn't see that issue linked here.
Back to top
View user's profile Send private message
-Fin-roller
n00b
n00b


Joined: 13 Aug 2015
Posts: 14
Location: Paimio

PostPosted: Fri Sep 04, 2015 6:02 am    Post subject: Reply with quote

I've been running vdevd (and libudev-compat, but not vdevfs) on Gentoo for a few weeks (or so?) now. There's been problems and vdev is still under very heavy development, but not real showstoppers. I mean, I got Xorg working with hardware graphics acceleration, sound works, input devices work and my hds work all fine with it.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Sep 04, 2015 2:16 pm    Post subject: Reply with quote

-Fin-roller wrote:
I've been running vdevd (and libudev-compat, but not vdevfs) on Gentoo for a few weeks (or so?) now. There's been problems and vdev is still under very heavy development, but not real showstoppers. I mean, I got Xorg working with hardware graphics acceleration, sound works, input devices work and my hds work all fine with it.

That's excellent news, thanks :-)

Could you tell us a bit more, as to what specific packages you emerged, and from where (ebuilds)?

The output from emerge -pv vdev libudev-compat (in a code tag) if those were all, would be really cool too, so we can see what USE flags you're using.
Back to top
View user's profile Send private message
-Fin-roller
n00b
n00b


Joined: 13 Aug 2015
Posts: 14
Location: Paimio

PostPosted: Fri Sep 04, 2015 4:43 pm    Post subject: Reply with quote

Sorry, I'm not sure if I detected some sarcasm here :) I didn't use an ebuild, although there might be one at (https://github.com/tokiclover/bar-overlay/tree/master/sys-fs/vdev) As I don't know much shell scripting, I edited a working one for vdevd using this: https://gist.github.com/geki-yaba/905dac9ccbfe448d121b

Edit: I got eudev installed and just copied over the libudev.so provided by libudev-compat to replace /lib64/libudev.so
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Sep 05, 2015 11:01 am    Post subject: Reply with quote

-Fin-roller wrote:
Sorry, I'm not sure if I detected some sarcasm here :)
Huh? No.
Just trying to answer augustin's query, and read some real-life usage experience.
Quote:
I didn't use an ebuild, although there might be one at (https://github.com/tokiclover/bar-overlay/tree/master/sys-fs/vdev)
OK good; minor tweaks needed, but nothing show-stopping.
Quote:
As I don't know much shell scripting, I edited a working one for vdevd using this: https://gist.github.com/geki-yaba/905dac9ccbfe448d121b
Hmm that's an init script and conf right? Seems like some of that could be integrated with tclover's initscript, though it needs work on the shell.
#bash on IRC: chat.freenode.net will teach you sh if you specify that upfront.

OFC we can clean it up; just thought you'd want to improve.
See the POSIX sh doc, shelldorado and grymoire.
Quote:
I got eudev installed and just copied over the libudev.so provided by libudev-compat to replace /lib64/libudev.so

Well it's good it works, but I don't think that's going to be a viable option going forward; the idea is to replace e?udev.
Though that is a ringing endorsement :-)
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Sep 06, 2015 1:18 pm    Post subject: Reply with quote

-Fin-roller wrote:
I got eudev installed and just copied over the libudev.so provided by libudev-compat to replace /lib64/libudev.so

steveL wrote:
Well it's good it works, but I don't think that's going to be a viable option going forward; the idea is to replace e?udev.
Though that is a ringing endorsement :-)

Actually I'm wrong on the way forward; sorry to sound like a downer. As my boss put it:
Code:
Since systemd-udev were so gracious as to gobble up projects like pci-ids and hwdb,
 and extinguish them as independent options, we don't have much choice.

Certainly simple enough to do, with a vdev USE flag added to eudev; just
Code:
use vdev && rm -f "$D/$(get_libdir)"/libudev.so*
in src_install(), after the emake install/default.

Then make eudev[vdev] RDEPEND on vdevd[eudev], and in the vdevd ebuild, make a hardlink from libudev-compat.so to libudev.so.X.Y, and an unversioned symlink to that, if use eudev.

Again, sorry if I came across as condescending (which wasn't my intent.) I was wrong.
Back to top
View user's profile Send private message
-Fin-roller
n00b
n00b


Joined: 13 Aug 2015
Posts: 14
Location: Paimio

PostPosted: Sun Sep 06, 2015 5:04 pm    Post subject: Reply with quote

That sounds like it could work like that. I'm not sure how much vdevd/libudev-compat depend on stuff provided by eudev on my system. At least they come with hwdb of their own.

As for the ebuild and init scripts. I've never written one of either and I only partially understand the ones I've edited. The init script I use at the moment includes a c program I wrote because I couldn't fix the part of the script that didn't work. It sort of works, but it's not the way it's supposed to be done (you know problems start to look like nails when all you have is a hammer? :) ). That being said, I'm reading about ebuilds and bash scripting atm and maybe if off-computer-world spares me some time to actually learn stuff, I'll eventually get something working done.

In the meanwhile, you think I could just emerge -C eudev and see if anything breaks down (I mean until next installs that require virtual/udev to be installed :)...
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Sep 09, 2015 9:26 am    Post subject: Reply with quote

-Fin-roller wrote:
That sounds like it could work like that. I'm not sure how much vdevd/libudev-compat depend on stuff provided by eudev on my system. At least they come with hwdb of their own.

Ah ok, good to know; yeah it can't rely on eudev, or it wouldn't work.
Quote:
As for the ebuild and init scripts. I've never written one of either and I only partially understand the ones I've edited. The init script I use at the moment includes a c program I wrote because I couldn't fix the part of the script that didn't work. It sort of works, but it's not the way it's supposed to be done (you know problems start to look like nails when all you have is a hammer? :) ). That being said, I'm reading about ebuilds and bash scripting atm and maybe if off-computer-world spares me some time to actually learn stuff, I'll eventually get something working done.

OK, there's some info on bash here which should be helpful, for ebuilds.

For initscripts, it's all POSIX sh, though we can use 'local' as well. (It's a mistake to assume it gives dynamic scope like bash, though I've seen that assumption just yesterday, but can't recall what initscript it was.)
Quote:
In the meanwhile, you think I could just emerge -C eudev and see if anything breaks down (I mean until next installs that require virtual/udev to be installed :)...

So long as you have a live-disk to hand, sure. ;-)
Back to top
View user's profile Send private message
-Fin-roller
n00b
n00b


Joined: 13 Aug 2015
Posts: 14
Location: Paimio

PostPosted: Thu Sep 10, 2015 7:27 am    Post subject: Reply with quote

emerge -C eudev was a bit anticlimatic as nothing broke down. I don't use THAT many packages that use udev though. Only two things I have problem with right now are that my digital camera doesn't work in shotwell (which is being looked at by Jude in github atm) and compiling (32bit) libusb fails for now because I don't have a 32-bit libudev.so.

Those are dealable problems though and I really should start writing a working init script (in sh instead of random c). There's one problem with my init script at the moment (about which I can ask again about later when I got a reasonable init script written, but thought of mentioning it already):
Vdevd is in sysinit runlevel and it does start and does enable a lot of devices, for example framebuffer (judging by the nicer looking console), but when i get to log in, I can see that a lot of stuff didn't get "detected". For example /run/udev/links (/run/udev is a symbolic link to a libudev-compat created directory /dev/metadata/udev) is empty and it should have all kinds of directories/files. Anyhow, at this point I restart vdevd and the stuff in /run/udev gets created there correctly. So I'm wondering if this is a runlevel related problem. Is it even possible to drop the device manager from sysinit to say default and what would that mean.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Sep 22, 2015 10:24 am    Post subject: Reply with quote

You probably want to drop it to boot, not default, Fin.

udev originally had two startup scripts, one in sysinit, and postmount in boot after localmount.
The requirement changed so that the equivalent of localmount (esp /usr but also /var and /opt etc) is done before udev is started.

That was why I did the patches to start udev after localmount, for those of us not using an initramfs, but with a split /usr. (Yes, need to do a later version.)
If you have your mobo and fs drivers built-in to the kernel, as most Gentoo users setup as part of install, you don't need an initramfs, unless you have the root partition on lvm or mdraid etc: the exact same situation where you used to need an initrd.

Anyhow, you will probably find these sh functions useful; they're what I use to inspect initscript dependencies, when mucking around with udev startup.
Seems like a similar problem.

The worst that can happen is you need to reboot from a live-disk, chroot in and rc-update to reset.
Usually you can do that from a "panic shell" as just rootfs is enough. ie: editing the grub command line to add/mod: init=/bin/bash.
We had to do quite a lot of that initially, for the udev patches.

HTH.

edit: Oh, if you want to learn sh properly, this is the documentation you need to download.
#bash on IRC: chat.freenode.net (or .org)will teach you POSIX sh, if you specify that's what you're doing upfront. Highly recommended channel, as practically every regular in there is a professional sysadmin, and uses bash for a living.

If you're into C, coming up into sh is lovely. ;-)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum