- dev - passt

Re: [PATCH v5 3/3] tcp: allow retransmit when peer receive window is zero
by Stefano Brivio 17 May '24

17 May '24

On Thu, 16 May 2024 22:39:53 -0400 Jon Maloy <jmaloy(a)redhat.com> wrote: > On 2024-05-16 18:21, Stefano Brivio wrote: > > On Thu, 16 May 2024 17:33:28 -0400 > > Jon Maloy <jmaloy(a)redhat.com> wrote: > > > >> A bug in kernel TCP may lead to a deadlock where a zero window is sent > >> from the peer, while it is unable to send out window updates even after > >> reads have freed up enough buffer space to permit a larger window. > >> In this situation, new window advertisemnts from the peer can only be > >> triggered by packets arriving from this side. > >> > >> However, such packets are never sent, because the zero-window condition > >> currently prevents this side from sending out any packets whatsoever > >> to the peer. > >> > >> We notice that the above bug is triggered *only* after the peer has > >> dropped an arriving packet because of severe memory squeeze, and that we > >> hence always enter a retransmission situation when this occurs. This > >> also means that it goes against the RFC 9293 recommendation that a > >> previously advertised window never should shrink. > >> > >> RFC 9293 gives the solution to this situation. In chapter 3.6.1 we find > >> the following statement: > >> "A TCP receiver SHOULD NOT shrink the window, i.e., move the right > >> window edge to the left (SHLD-14). However, a sending TCP peer MUST > >> be robust against window shrinking, which may cause the > >> "usable window" (see Section 3.8.6.2.1) to become negative (MUST-34). > >> > >> If this happens, the sender SHOULD NOT send new data (SHLD-15), but > >> SHOULD retransmit normally the old unacknowledged data between SND.UNA > >> and SND.UNA+SND.WND (SHLD-16). The sender MAY also retransmit old data > >> beyond SND.UNA+SND.WND (MAY-7)" > >> > >> We never see the window become negative, but we interpret this as a > >> recommendation to use the previously available window during > >> retransmission even when the currently advertised window is zero. > >> > >> We use the above mechanism only for timer-induced retransmits, while > >> the fast-retransmit mechanism won't trigger on this condition. > >> > >> It should be noted that although this solves the problem we have at > >> hand, it is not a genuine solution to the kernel bug. There may well > >> be TCP stacks around in other OS-es which don't do this, nor have > >> keep-alive probing as an alternatve way to solve the situation. > >> > >> Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> > >> > >> --- > >> v2: - Using previously advertised window during retransmission, instead > >> highest send sequencece number in the cycle. > >> v3: - Rebased to newest code > >> - Changes based on feedback from PASST team > >> - Sending out empty probe message at timer expiration when > >> we are not in retransmit situation. > >> v4: - Some small changes based on feedback from PASST team. > >> - Replaced fast retransmit with a one-time 'fast probe' when > >> window is zero. > >> v5: - Gave up on 'fast probing' for now. When I got the sequence > >> numbers right in the flag message (after having emptied the tap > >> queue), it turns out an empty message does *not* force a new peer > >> window update as was my previous understanding of the code. > >> - Added cppcheck suppression line (which I was unable to verify) > > ...hmm, why? All it takes is a 'make cppcheck'. Or is your version of > > cppcheck not showing it? > Exactly. My version is too recent, I think. > > > >> as suggested by S. Brivio. > >> - Removed sending of empty probe when window from tap side is zero. > >> It looks pointless at the moment, at least for solving the above > >> described situation. > > So, as far as I understand, this patch now doesn't introduce any > > functional change, except that if an existing timer happened to be > > pending (this patch never schedules it), > > and the window _we_ are > > advertising (wnd_to_tap) is zero (I'm not sure why that's relevant), > > then we'll send an ACK segment. > The change is that we really will do a retransmit from the timer handler, > ignoring that current window is zero. ...but how does the window *we* advertise matter here? You're checking conn->wnd_to_tap now, not conn->wnd_from_tap. Anyway, if you're now abandoning this approach, it doesn't matter. > This solves the deadlock problem > I have been describing, but it is not a good solution. > > One problem is that new incoming data will cause an EPOLLIN event, > which will cause a call to tcp_data_from_sock(), which will also ignore > the zero-window. Right now it doesn't ignore it. Do you plan to use that function to check if the usable window is now negative (because the window value is zero but we have unacknowledged data), and re-send something in that case? > This is easy to fix, I realize: > > if (events & EPOLLIN && conn->wnd_from_tap) > tcp_data_from_sock(c, conn); > > The next is that I would like to start a short timer when I receive > the zero-window and seq_to_tap > seq_ack_from_tap (same condition > as in previous versions, but without sending the flag packet). > As far as I can see there is no simple way to schedule the timer to > the value I want. I am open to suggestions here. You could reuse/abuse ACK_TO_TAP_DUE (after all, you want to send a keep-alive in a while), and schedule a different timeout in tcp_timer_ctl() if the peer window is zero. Then, in the timer handler, depending on the peer window, you would check if you want to use ACK_IF_NEEDED (no keepalive), or ACK (force a keepalive in any case). -- Stefano

2 1

[PATCH] util, tcp: Add helper to display socket addresses
by David Gibson 16 May '24

16 May '24

When reporting errors, we sometimes want to show a relevant socket address. Doing so by extracting the various relevant fields can be pretty awkward, so introduce a sockaddr_ntop() helper to make it simpler. For now we just have one user in tcp.c, but I have further upcoming patches which can make use of it. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- tcp.c | 23 +++++++++-------------- util.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ util.h | 4 ++++ 3 files changed, 57 insertions(+), 14 deletions(-) diff --git a/tcp.c b/tcp.c index 21d0af0..efbbc1c 100644 --- a/tcp.c +++ b/tcp.c @@ -2758,6 +2758,7 @@ static void tcp_tap_conn_from_sock(struct ctx *c, in_port_t dstport, void tcp_listen_handler(struct ctx *c, union epoll_ref ref, const struct timespec *now) { + char sastr[SOCKADDR_STRLEN]; union sockaddr_inany sa; socklen_t sl = sizeof(sa); union flow *flow; @@ -2776,25 +2777,15 @@ void tcp_listen_handler(struct ctx *c, union epoll_ref ref, if (IN4_IS_ADDR_UNSPECIFIED(addr) || IN4_IS_ADDR_BROADCAST(addr) || - IN4_IS_ADDR_MULTICAST(addr) || port == 0) { - char str[INET_ADDRSTRLEN]; - - err("Invalid endpoint from TCP accept(): %s:%hu", - inet_ntop(AF_INET, addr, str, sizeof(str)), port); - goto cancel; - } + IN4_IS_ADDR_MULTICAST(addr) || port == 0) + goto bad_endpoint; } else if (sa.sa_family == AF_INET6) { const struct in6_addr *addr = &sa.sa6.sin6_addr; in_port_t port = sa.sa6.sin6_port; if (IN6_IS_ADDR_UNSPECIFIED(addr) || - IN6_IS_ADDR_MULTICAST(addr) || port == 0) { - char str[INET6_ADDRSTRLEN]; - - err("Invalid endpoint from TCP accept(): %s:%hu", - inet_ntop(AF_INET6, addr, str, sizeof(str)), port); - goto cancel; - } + IN6_IS_ADDR_MULTICAST(addr) || port == 0) + goto bad_endpoint; } if (tcp_splice_conn_from_sock(c, ref.tcp_listen.pif, @@ -2804,6 +2795,10 @@ void tcp_listen_handler(struct ctx *c, union epoll_ref ref, tcp_tap_conn_from_sock(c, ref.tcp_listen.port, flow, s, &sa, now); return; +bad_endpoint: + err("Invalid endpoint from TCP accept(): %s", + sockaddr_ntop(&sa, sastr, sizeof(sastr))); + cancel: flow_alloc_cancel(flow); } diff --git a/util.c b/util.c index 849fa7f..c78a5f3 100644 --- a/util.c +++ b/util.c @@ -553,3 +553,47 @@ int write_remainder(int fd, const struct iovec *iov, int iovcnt, size_t skip) return 0; } + + +/** sockaddr_ntop - Convert a socket address to text format + * @src: Socket address + * @dst: output buffer, minimum SOCKADDR_STRLEN bytes + * @size: size of buffer at @dst + * + * Return: On success, a non-null pointer to @dst, NULL on failure + */ +const char *sockaddr_ntop(const void *sa, char *dst, socklen_t size) +{ + sa_family_t family = ((const struct sockaddr *)sa)->sa_family; + + switch (family) { + case AF_INET: { + const struct sockaddr_in *sa4 = sa; + char addr[INET_ADDRSTRLEN]; + + if (!inet_ntop(AF_INET, &sa4->sin_addr, addr, sizeof(addr))) + break; + + snprintf(dst, size, "%s:%hu", addr, ntohs(sa4->sin_port)); + return dst; + } + + case AF_INET6: { + const struct sockaddr_in6 *sa6 = sa; + char addr[INET6_ADDRSTRLEN]; + + if (!inet_ntop(AF_INET6, &sa6->sin6_addr, addr, sizeof(addr))) + break; + + snprintf(dst, size, "[%s]:%hu", addr, ntohs(sa6->sin6_port)); + return dst; + } + + /* FIXME: Implement AF_UNIX */ + default: + errno = EAFNOSUPPORT; + } + + /* Failure */ + return NULL; +} diff --git a/util.h b/util.h index 264423b..2c7154e 100644 --- a/util.h +++ b/util.h @@ -180,6 +180,10 @@ static inline const char *af_name(sa_family_t af) } } +#define SOCKADDR_STRLEN MAX(INET_ADDRSTRLEN + 6, \ + INET6_ADDRSTRLEN + 8) +const char *sockaddr_ntop(const void *sa, char *dst, socklen_t size); + /** * mod_sub() - Modular arithmetic subtraction * @a: Minued, unsigned value < @m -- 2.45.0

2 2

[PATCH v4] tcp: move seq_to_tap update to when frame is queued
by Jon Maloy 15 May '24

15 May '24

commit a469fc393fa1 ("tcp, tap: Don't increase tap-side sequence counter for dropped frames") delayed update of conn->seq_to_tap until the moment the corresponding frame has been successfully pushed out. This has the advantage that we immediately can make a new attempt to transmit a frame after a failed trasnmit, rather than waiting for the peer to later discover a gap and trigger the fast retransmit mechanism to solve the problem. This approach has turned out to cause a problem with spurious sequence number updates during peer-initiated retransmits, and we have realized it may not be the best way to solve the above issue. We now restore the previous method, by updating the said field at the moment a frame is added to the outqueue. To retain the advantage of having a quick re-attempt based on local failure detection, we now scan through the part of the outqueue that had do be dropped, and restore the sequence counter for each affected connection to the most appropriate value. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- v2: - Re-spun loop in tcp_revert_seq() and some other changes based on feedback from Stefano Brivio. - Added paranoid test to avoid that seq_to_tap becomes lower than seq_ack_from_tap. v3: - Identical to v2. Called v3 because it was embedded in a series with that version. v4: - In tcp_revert_seq(), we read the sequence number from the TCP header instead of keeping a copy in struct tcp_buf_seq_update. - Since the only remaining field in struct tcp_buf_seq_update is a pointer to struct tcp_tap_conn, we eliminate the struct altogether, and make the tcp6/tcp3_buf_seq_update arrays into arrays of said pointer. - Removed 'paranoid' test in tcp_revert_seq. If it happens, it is not fatal, and will be caught by other code anyway. - Separated from the series again. --- tcp.c | 59 +++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 37 insertions(+), 22 deletions(-) diff --git a/tcp.c b/tcp.c index 21d0af0..976dba8 100644 --- a/tcp.c +++ b/tcp.c @@ -410,16 +410,6 @@ static int tcp_sock_ns [NUM_PORTS][IP_VERSIONS]; */ static union inany_addr low_rtt_dst[LOW_RTT_TABLE_SIZE]; -/** - * tcp_buf_seq_update - Sequences to update with length of frames once sent - * @seq: Pointer to sequence number sent to tap-side, to be updated - * @len: TCP payload length - */ -struct tcp_buf_seq_update { - uint32_t *seq; - uint16_t len; -}; - /* Static buffers */ /** * struct tcp_payload_t - TCP header and data to send segments with payload @@ -461,7 +451,8 @@ static struct tcp_payload_t tcp4_payload[TCP_FRAMES_MEM]; static_assert(MSS4 <= sizeof(tcp4_payload[0].data), "MSS4 is greater than 65516"); -static struct tcp_buf_seq_update tcp4_seq_update[TCP_FRAMES_MEM]; +/* References tracking the owner connection of frames in the tap outqueue */ +static struct tcp_tap_conn *tcp4_frame_conns[TCP_FRAMES_MEM]; static unsigned int tcp4_payload_used; static struct tap_hdr tcp4_flags_tap_hdr[TCP_FRAMES_MEM]; @@ -483,7 +474,8 @@ static struct tcp_payload_t tcp6_payload[TCP_FRAMES_MEM]; static_assert(MSS6 <= sizeof(tcp6_payload[0].data), "MSS6 is greater than 65516"); -static struct tcp_buf_seq_update tcp6_seq_update[TCP_FRAMES_MEM]; +/* References tracking the owner connection of frames in the tap outqueue */ +static struct tcp_tap_conn *tcp6_frame_conns[TCP_FRAMES_MEM]; static unsigned int tcp6_payload_used; static struct tap_hdr tcp6_flags_tap_hdr[TCP_FRAMES_MEM]; @@ -1261,25 +1253,49 @@ static void tcp_flags_flush(const struct ctx *c) tcp4_flags_used = 0; } +/** + * tcp_revert_seq() - Revert affected conn->seq_to_tap after failed transmission + * @conns: Array of connection pointers corresponding to queued frames + * @frames: Two-dimensional array containing queued frames with sub-iovs + * @num_frames: Number of entries in the two arrays to be compared + */ +static void tcp_revert_seq(struct tcp_tap_conn **conns, struct iovec *frames, + int num_frames) +{ + int c, f; + + for (c = 0, f = 0; c < num_frames; c++, f += TCP_NUM_IOVS) { + struct tcp_tap_conn *conn = conns[c]; + struct tcphdr *th = frames[f + TCP_IOV_PAYLOAD].iov_base; + uint32_t seq = ntohl(th->seq); + + if (SEQ_LE(conn->seq_to_tap, seq)) + continue; + + conn->seq_to_tap = seq; + } +} + /** * tcp_payload_flush() - Send out buffers for segments with data * @c: Execution context */ static void tcp_payload_flush(const struct ctx *c) { - unsigned i; size_t m; m = tap_send_frames(c, &tcp6_l2_iov[0][0], TCP_NUM_IOVS, tcp6_payload_used); - for (i = 0; i < m; i++) - *tcp6_seq_update[i].seq += tcp6_seq_update[i].len; + if (m != tcp6_payload_used) + tcp_revert_seq(tcp6_frame_conns, &tcp6_l2_iov[m][0], + tcp6_payload_used - m); tcp6_payload_used = 0; m = tap_send_frames(c, &tcp4_l2_iov[0][0], TCP_NUM_IOVS, tcp4_payload_used); - for (i = 0; i < m; i++) - *tcp4_seq_update[i].seq += tcp4_seq_update[i].len; + if (m != tcp4_payload_used) + tcp_revert_seq(tcp4_frame_conns, &tcp4_l2_iov[m][0], + tcp4_payload_used - m); tcp4_payload_used = 0; } @@ -2129,10 +2145,11 @@ static int tcp_sock_consume(const struct tcp_tap_conn *conn, uint32_t ack_seq) static void tcp_data_to_tap(const struct ctx *c, struct tcp_tap_conn *conn, ssize_t dlen, int no_csum, uint32_t seq) { - uint32_t *seq_update = &conn->seq_to_tap; struct iovec *iov; size_t l4len; + conn->seq_to_tap = seq + dlen; + if (CONN_V4(conn)) { struct iovec *iov_prev = tcp4_l2_iov[tcp4_payload_used - 1]; const uint16_t *check = NULL; @@ -2142,8 +2159,7 @@ static void tcp_data_to_tap(const struct ctx *c, struct tcp_tap_conn *conn, check = &iph->check; } - tcp4_seq_update[tcp4_payload_used].seq = seq_update; - tcp4_seq_update[tcp4_payload_used].len = dlen; + tcp4_frame_conns[tcp4_payload_used] = conn; iov = tcp4_l2_iov[tcp4_payload_used++]; l4len = tcp_l2_buf_fill_headers(c, conn, iov, dlen, check, seq); @@ -2151,8 +2167,7 @@ static void tcp_data_to_tap(const struct ctx *c, struct tcp_tap_conn *conn, if (tcp4_payload_used > TCP_FRAMES_MEM - 1) tcp_payload_flush(c); } else if (CONN_V6(conn)) { - tcp6_seq_update[tcp6_payload_used].seq = seq_update; - tcp6_seq_update[tcp6_payload_used].len = dlen; + tcp6_frame_conns[tcp6_payload_used] = conn; iov = tcp6_l2_iov[tcp6_payload_used++]; l4len = tcp_l2_buf_fill_headers(c, conn, iov, dlen, NULL, seq); -- 2.42.0

2 3

[PATCH v3 0/3] Support for SO_PEEK_OFF socket option
by Jon Maloy 14 May '24

14 May '24

Rebased, plus latest changes based on feedback. Jon Maloy (3): tcp: move seq_to_tap update to when frame is queued tcp: leverage support of SO_PEEK_OFF socket option when available tcp: allow retransmit when peer receive window is zero tcp.c | 182 +++++++++++++++++++++++++++++++++++++++-------------- tcp_conn.h | 2 + 2 files changed, 138 insertions(+), 46 deletions(-) -- 2.42.0

3 12

[PATCH v4 00/16] RFC: Unified flow table
by David Gibson 14 May '24

14 May '24

This is a fourth draft of the first steps in implementing more general "connection" tracking, as described at: https://pad.passt.top/p/NewForwardingModel This series changes the TCP connection table and hash table into a more general flow table that can track other protocols as well. Each flow uniformly keeps track of all the relevant addresses and ports, which will allow for more robust control of NAT and port forwarding. ICMP is converted to use the new flow table. This doesn't include UDP, but I'm working on it right now and making progress. I'm posting this to give a head start on the review :) Caveats: * We significantly increase the size of a connection/flow entry - Can probably be mitigated, but I haven't investigated much yet * We perform a number of extra getsockname() calls to know some of the socket endpoints - Haven't yet measured how much performance impact that has - Can be mitigated in at least some cases, but again, haven't tried yet Changes since v4: * Complex rebase on top of the many things that have happened upstream since v3. * Assorted other changes. Changes since v3: * Replace TAPFSIDE() and SOCKFSIDE() macros with local variables. Changes since v2: * Cosmetic fixes based on review * Extra doc comments for enum flow_type * Rename flowside to flowaddrs which turns out to make more sense in light of future changes * Fix bug where the socket flowaddrs for tap initiated connections wasn't initialised to match the socket address we were using in the case of map-gw NAT * New flowaddrs_from_sock() helper used in most cases which is cleaner and should avoid bugs like the above * Using newer centralised workarounds for clang-tidy issue 58992 * Remove duplicate definition of FLOW_MAX as maximum flow type and maximum number of tracked flows * Rebased on newer versions of preliminary work (ICMP, flow based dispatch and allocation, bind/address cleanups) * Unified hash table as well as base flow table * Integrated ICMP Changes since v1: * Terminology changes - "Endpoint" address/port instead of "correspondent" address/port - "flowside" instead of "demiflow" * Actually move the connection table to a new flow table structure in new files * Significant rearrangement of earlier patchs on top of that new table, to reduce churn David Gibson (16): flow: Common data structures for tracking flow addresses tcp: Maintain flowside information for "tap" connections tcp_splice: Maintain flowside information for spliced connections tcp: Obtain guest address from flowside tcp: Simplify endpoint validation using flowside information tcp, tcp_splice: Construct sockaddrs for connect() from flowside tcp_splice: Eliminate SPLICE_V6 flag tcp, flow: Replace TCP specific hash function with general flow hash flow, tcp: Generalise TCP hash table to general flow hash table tcp: Re-use flow hash for initial sequence number generation icmp: Populate flowside information icmp: Use flowsides as the source of truth wherever possible icmp: Look up ping flows using flow hash icmp: Eliminate icmp_id_map flow, tcp: flow based NAT and port forwarding for TCP flow, icmp: Use general flow forwarding rules for ICMP flow.c | 199 ++++++++++++++++++++- flow.h | 97 +++++++++++ fwd.c | 139 +++++++++++++++ fwd.h | 5 + icmp.c | 83 +++++---- icmp_flow.h | 1 - inany.h | 29 +++- passt.h | 3 + pif.h | 1 - tap.c | 11 -- tap.h | 1 - tcp.c | 475 +++++++++++++-------------------------------------- tcp_conn.h | 20 +-- tcp_splice.c | 93 ++-------- tcp_splice.h | 5 +- 15 files changed, 649 insertions(+), 513 deletions(-) -- 2.44.0

2 22

[PATCH] apparmor: allow netns paths on /tmp
by Paul Holzinger 13 May '24

13 May '24

For some unknown reason "owner" makes it impossible to open bind mounted netns references as apparmor denies it. In the kernel denied log entry we see ouid=0 but it is not clear why that is as the actual file is owned by the real (rootless) user id. In abstractions/pasta there is already `@{run}/user/@{uid}/**` without owner set for the same reason as this path contains the netns path by default when running under Podman. Fixes: 72884484b00d ("apparmor: allow read access on /tmp for pasta") Signed-off-by: Paul Holzinger <pholzing(a)redhat.com> --- contrib/apparmor/usr.bin.pasta | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/apparmor/usr.bin.pasta b/contrib/apparmor/usr.bin.pasta index 2a4d28c..bdfeb71 100644 --- a/contrib/apparmor/usr.bin.pasta +++ b/contrib/apparmor/usr.bin.pasta @@ -19,7 +19,7 @@ profile pasta /usr/bin/pasta{,.avx2} flags=(attach_disconnected) { include <abstractions/pasta> # Alternatively: include <abstractions/user-tmp> - owner /tmp/** rw, # tap_sock_unix_init(), pcap(), + /tmp/** rw, # tap_sock_unix_init(), pcap(), # write_pidfile(), # logfile_init(), # pasta_open_ns() -- 2.45.0

2 1

[PATCH v2 0/2] LLVM 18.1.1 / Fedora 40 clang-tidy fixes
by David Gibson 13 May '24

13 May '24

A new clang-tidy has introduce some new warnings. David Gibson (2): conf: Fix clang-tidy warning about using an undefined enum value clang-tidy: Suppress macro to enum conversion warnings Makefile | 9 ++++++++- conf.c | 4 ++-- fwd.h | 1 + 3 files changed, 11 insertions(+), 3 deletions(-) -- 2.45.0

2 3

[PATCH] passt.c: explicitly include libgen.h for basename
by lemmi 13 May '24

13 May '24

fixes implicit declaration warning on musl Signed-off-by: lemmi <lemmi(a)nerd2nerd.org> --- passt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/passt.c b/passt.c index e93b6be..771b8a7 100644 --- a/passt.c +++ b/passt.c @@ -35,6 +35,7 @@ #include <syslog.h> #include <sys/prctl.h> #include <netinet/if_ether.h> +#include <libgen.h> #ifdef HAS_GETRANDOM #include <sys/random.h> #endif -- 2.45.0

3 2

Setting hostname while spawning pasta
by Danish Prakash 13 May '24

13 May '24

Hello I was having a discussion with a colleague of mine on how `pasta` when invoked independently drops you in a new user and network namespace and how that causes some folks to not realize what has happened especially because there's no cue as to what transpired. This is not uncommon though, because a lot of times, folks having issues with pasta while running it with podman, tend to invoke pasta directly to debug. I interacted with Stefano regarding this and he told me that pasta already detaches the UTS namespace and so in order to address this issue, I propose that we set the hostname as part of `pasta_spawn_cmd()`.Doing this would provide users with a clear visual indication that they are in a new user namespace (among other ns but that won't be indicative here) and avoid issues similar to the aforementioned. I'm looking to gather more opinions on how this change, if implemented, would affect the functionality. Looking forward to the discussion. Thank you danishpraka.sh :wq

3 4

Re: Setting hostname while spawning pasta
by Stefano Brivio 13 May '24

13 May '24

On Mon, 13 May 2024 13:45:51 +0530 Danish Prakash <danish.prakash(a)suse.com> wrote: > > But we could still retain the existing hostname and prefix with > > something like 'pasta-on-' (sure, we would need to truncate at 63 > > characters, but it shouldn't be a common case). What do you think? > > That sounds like a good idea. I didn't realize you'd be running > pasta-in-pasta.. but that's reasonable. Though this will be helpful, > I'm not entirely sure if this would override the prompts that many > have set. At least my rudimentary shell prompt doesn't recognize the > pasta user namespace and continues to show the same old prompt. I hope > I'm the only one having this issue. I currently have these behaviours with default prompts: - Alpine: host:~$ pasta host:~# - Debian: user@host:~$ pasta root@host:~# - Fedora: [user@host ~]$ pasta [root@host ~]# - openSUSE: user@host:~> pasta host:~ # so I generally have a hint of something going on, but in any case, changing the hostname is helpful for unfamiliar users or even just for the pasta-in-pasta case I mentioned. > > What I can't tell from the prompt, though, is at what "level" I'm at > > (at least pasta-in-pasta is something I try very commonly to reproduce > > pasta's behaviour with particular network setups). Having > > root@pasta-on-pasta-on-machine would be a nice plus. > > But in general, this idea sounds good, I'd like to take a shot at > this, and I can send over the patch for you to test once I'm done. > What do you think? Sure, thanks, looking forward to it! -- Stefano

2 1