On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> Maybe someone here knows how the ownership of these files for Dovecot needs
> to be in order to work, as various distributions of Dovecot packages seem
> to use different users:
> I'd like Dovecot not to log into syslog, but to dedicated
On 5/12/24 21:30, David Wright wrote:
On Sun 12 May 2024 at 21:10:16 (-0700), Paul Scott wrote:
On 5/9/2024 1:59 PM, Charles Curley wrote:
On Thu, 9 May 2024 09:32:32 -0700 Paul Scott wrote:
The error I'm getting is during "Install base system." The only way
I knew to save the log was
On Mon, May 13, 2024 at 08:37:16PM +0200, Erwan David wrote:
> Le 13/05/2024 à 19:45, Stefan Monnier a écrit :
[...]
> > % sudo zsh -l
> > # echo 1 > /proc/sys/net/ipv4/ip_forward
> > # ^D
> > logout
> > %
> >
> >
> >
> >
> > Stefan
> >
> >
> sudo -i will
On 14/5/24 04:16, Richard wrote:
Maybe someone here knows how the ownership of these files for Dovecot
needs to be in order to work, as various distributions of Dovecot
packages seem to use different users:
I'd like Dovecot not to log into syslog, but to dedicated files.
Therefore I've
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> Maybe someone here knows how the ownership of these files for Dovecot needs
> to be in order to work, as various distributions of Dovecot packages seem
> to use different users:
> I'd like Dovecot not to log into syslog, but to dedicated
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=,
> > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred
> > (temporary failure. Command output: lda(user): Error:
> >
Maybe someone here knows how the ownership of these files for Dovecot needs
to be in order to work, as various distributions of Dovecot packages seem
to use different users:
I'd like Dovecot not to log into syslog, but to dedicated files. Therefore
I've created the directory /var/log/dovecot and
yeah at the beginning i used xorg + xfce but then i realized that i did not
need them,so the context became the textual mode.
Il lun 13 mag 2024, 21:52 David Wright ha
scritto:
> On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote:
> > On Mon, May 13, 2024 at 9:05 PM Greg Wooledge
On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote:
> On Mon, May 13, 2024 at 9:05 PM Greg Wooledge wrote:
> > On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:
> > > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:
> > > > On Mon, May 13, 2024 at 07:36:07AM +0200,
Le dimanche 12 mai 2024 à 15:23 +0200, didier gaumet a écrit :
>
> donc en gros je pense que tu n'as rien à faire, qu'avec le temps, les
> paquets Debian le nécessitant seront modifiés et que les dépôts le
> nécessitant seront signés par des clés plus robustes (algo' plus
> fiable)
>
>
Bon,
---> The context has been snipped out
nope. Read well what I said on my first post :
*[Forgot to say that I switched boot target to text with this command :*
*sudo systemctl set-default multi-user.target]*
What does this mean for you ? The context is that I was not using any
desktop
On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:
> Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:
> > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > > .profile
>
> Sorry, dumb question: Depending of the shell, the user is using (let's say,
> he
> will use
Le 13/05/2024 à 19:45, Stefan Monnier a écrit :
$ su -
Password:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ^D
logout
$
I don't need no stinkin' sudo :-)
And if you only have `sudo`, but not the root password, of course:
% sudo zsh -l
# echo 1 > /proc/sys/net/ipv4/ip_forward
#
On Mon, May 13, 2024 at 01:45:40PM -0400, Stefan Monnier wrote:
> > $ su -
> > Password:
> > # echo 1 > /proc/sys/net/ipv4/ip_forward
> > # ^D
> > logout
> > $
> >
> > I don't need no stinkin' sudo :-)
>
> And if you only have `sudo`, but not the root password, of course:
>
> % sudo zsh -l
>
> $ su -
> Password:
> # echo 1 > /proc/sys/net/ipv4/ip_forward
> # ^D
> logout
> $
>
> I don't need no stinkin' sudo :-)
And if you only have `sudo`, but not the root password, of course:
% sudo zsh -l
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ^D
logout
%
On 5/13/24 18:52, to...@tuxteam.de wrote:
Now share your ideas :-)
$ su -
Password:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ^D
logout
$
I don't need no stinkin' sudo :-)
regards,
chris
>> If yes, second dumb question: Coiuld it be ANY script or command?
>> (also running as non-rootuser, like adding "runuser -u myuser
>> command_whatever").
>Root can do this, yes.
Or to be more precise, .bashrc (and any file that's read from it like
.bash_aliases) can run anything the bash CLI
I think I have found my way,adding this line to /etc/sudoers :
marietto ALL=(ALL) NOPASSWD: /usr/bin/iptables
and on the warp script :
sudo /usr/bin/iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
On Mon, May 13, 2024 at 3:20 PM wrote:
> On Mon, May 13, 2024 at 09:17:31AM -0400,
Since this happens so often, I'm trying to offer a recap.
As others have noted, the above
sudo echo 1 > /proc/sys/net/ipv4/ip_forward
won't work, since it runs echo under sudo, but the file opening
(that pesky ">") happens in your shell, which is probably running
unprivileged (otherwise, what
Nobody has yet applauded this glorious implementation
of the 1960s GOTO statement in *Bash*?!
* Mario Marietto [24-05/13=Mo 13:37 +0200]:
> function jumpto
> {
> label=$1
> cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> eval "$cmd"
> exit
> }
Anyway,
Mario Marietto writes:
> There is still a problem. If I login automatically as user and inside
> the script I do this :
>
> sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
>
> it asks me for the password (don't know why it didn't before) but I
> can't issue a password,because
I don't have those typos in the code. The typo has been to copy the content
of the script by hand on the email message.
On Mon, May 13, 2024 at 6:30 PM Will Mengarini wrote:
> Nobody has yet applauded this glorious implementation
> of the 1960s GOTO statement in *Bash*?!
>
> * Mario Marietto
On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:
> Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:
> > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > > .profile
>
> Sorry, dumb question: Depending of the shell, the user is using (let's say,
> he
> will use
Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:
> On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > .profile
Sorry, dumb question: Depending of the shell, the user is using (let's say, he
will use bash), can the script not be added into ~/.bashrc?
If yes, second dumb
[image: Istantanea_2024-05-13_17-37-39.png]
Can someone explain to me why user "marietto" can't execute the command
iptables as root,without password ? thanks.
[image: Istantanea_2024-05-13_17-40-21.png]
On Mon, May 13, 2024 at 5:19 PM Mario Marietto
wrote:
> There is still a problem. If I
There is still a problem. If I login automatically as user and inside the
script I do this :
sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
it asks me for the password (don't know why it didn't before) but I can't
issue a password,because the script inside the vm should work
> You don't need to, but I definitely think he does.
^^
[ Oh, bias, when will you leave me alone? ]
Stefan
I've found that solution on the Internet. It wasn't the only solution that
I found,but that form won the challenge because it has found my mind ready
to detect that it could have worked. Maybe I could have used while,but
after 1 hour of thinking I didn't understand how and I resigned. The same
for
>> > echo 1 > /proc/sys/net/ipv4/ip_forward
>> This doesn't sound right. Maybe you should investigate why you're
> No need to “investigate”, the answer is obvious: in
You don't need to, but I definitely think he does.
Stefan
Mario Marietto (12024-05-13):
> The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
> doesn't work if invoked as a user,it says "you must be root". So,as
> user,the script seems to be working fine like this :
>
> function jumpto
> {
> label=$1
> cmd=$(sed -n
On Mon, May 13, 2024 at 09:17:31AM -0400, Greg Wooledge wrote:
> On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:
> > >> sudo xterm -e "echo 1 > hello"
>
> > Yes, but why did it allow me to delete the file? I was not root
> > then. Try it.
>
> Because you have write permission on the
Le 13/05/2024 à 15:03, Richmond a écrit :
Erwan David writes:
Le 13/05/2024 à 14:36, Richmond a écrit :
I was experimenting, and found this works:
sudo xterm -e "echo 1 > hello"
It created a file owned by root. But I found I was able to remove it
without being root even though group and
On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:
> >> sudo xterm -e "echo 1 > hello"
> Yes, but why did it allow me to delete the file? I was not root
> then. Try it.
Because you have write permission on the *directory* that the file is in.
Removing (unlinking) a file is an operation
The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
doesn't work if invoked as a user,it says "you must be root". So,as
user,the script seems to be working fine like this :
function jumpto
{
label=$1
cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
Richmond (12024-05-13):
> sudo bash -c "echo 1 > hello"
Use sh for that.
Regards,
--
Nicolas George
Erwan David writes:
> Le 13/05/2024 à 14:36, Richmond a écrit :
>> I was experimenting, and found this works:
>>
>> sudo xterm -e "echo 1 > hello"
>>
>> It created a file owned by root. But I found I was able to remove it
>> without being root even though group and world permissions were read
>>
writes:
> On Mon, May 13, 2024 at 01:36:23PM +0100, Richmond wrote:
>> I was experimenting, and found this works:
>>
>> sudo xterm -e "echo 1 > hello"
>
> That's like slicing your morning baguette with the chainsaw.
I do that too.
>
> But if it works for you... hey :-)
>
> Cheers
This also
Richmond wrote:
> I was experimenting, and found this works:
>
> sudo xterm -e "echo 1 > hello"
>
> It created a file owned by root. But I found I was able to remove it
> without being root even though group and world permissions were read
> only.
The owner of a directory can delete any file
On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote:
> to...@tuxteam.de (12024-05-13):
> > That's like slicing your morning baguette with the chainsaw.
>
> Worse than that, it will only work from an X11 environment. Certainly
> not at boot.
The analogy to that would be that not many
to...@tuxteam.de (12024-05-13):
> That's like slicing your morning baguette with the chainsaw.
Worse than that, it will only work from an X11 environment. Certainly
not at boot.
Regards,
--
Nicolas George
On Mon, May 13, 2024 at 01:36:23PM +0100, Richmond wrote:
> I was experimenting, and found this works:
>
> sudo xterm -e "echo 1 > hello"
That's like slicing your morning baguette with the chainsaw.
But if it works for you... hey :-)
Cheers
--
t
signature.asc
Description: PGP signature
Le 13/05/2024 à 14:36, Richmond a écrit :
I was experimenting, and found this works:
sudo xterm -e "echo 1 > hello"
It created a file owned by root. But I found I was able to remove it
without being root even though group and world permissions were read
only.
thats because sudo exceutes a
I was experimenting, and found this works:
sudo xterm -e "echo 1 > hello"
It created a file owned by root. But I found I was able to remove it
without being root even though group and world permissions were read
only.
Dan Ritter (12024-05-13):
> Mario Marietto wrote:> If you run
>
> sudo echo 1 > /proc/sys/net/ipv4/ip_forward
>
> then the shell you are running it from will run "sudo echo 1"
> and then try to put the output in that file.
Other way around: the shell first tries to redirect the output to the
Mario Marietto wrote:
> --> If they only want this thing to happen when root logs in directly on a
> console or ssh, then .profile may indeed be the correct answer.
>
> Yes,I don't need to run xorg and a desktop environment,since warp-cli
> disconnect and warp-cli connect do not require them.
>
Stefan Monnier (12024-05-13):
> > echo 1 > /proc/sys/net/ipv4/ip_forward
> >
> > work only if I'm root. It does not work using sudo.
> This doesn't sound right. Maybe you should investigate why you're
> seeing this behavior, rather than work around the problem.
>
> `sudo` *is* root.
No need to
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> work only if I'm root. It does not work using sudo.
This doesn't sound right. Maybe you should investigate why you're
seeing this behavior, rather than work around the problem.
`sudo` *is* root.
Stefan
On Mon, May 13, 2024 at 01:48:25PM +0200, Mario Marietto wrote:
> I wouldn't to login as root automatically,but I've realized that this
> command :
>
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> work only if I'm root. It does not work using sudo. So,in the end I've
> chosen to be root instead of
Le 13/05/2024 à 13:48, Mario Marietto a écrit :
--> If they only want this thing to happen when root logs in directly
on a console or ssh, then .profile may indeed be the correct answer.
Yes,I don't need to run xorg and a desktop environment,since warp-cli
disconnect and warp-cli connect do
--> If they only want this thing to happen when root logs in directly on a
console or ssh, then .profile may indeed be the correct answer.
Yes,I don't need to run xorg and a desktop environment,since warp-cli
disconnect and warp-cli connect do not require them.
I wouldn't to login as root
Hello to everyone,
Richard,thanks. I've launched the script inside the .profile file that's
inside the root folder and it worked. Thank you.
Plan B : From time to time the cloudflare connection stops working,so there
is the needing to repeat these commands :
warp-cli disconnect
warp-cli connect
On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> .profile
> will always be read as soon as the user logs in, no matter how. Through a
> terminal, a GUI, doesn't matter.
That's not correct. There are many different GUI login setups where
the .profile is never read.
That said, since
Bonjour,
Le find est tout à fait correct mis-à-part qu’il manquerait l’indication de la
racine. Si tu veux être certain duplique le répertoire racine avec un :
# rsync -Aavx MonRep/ MonRep-Sauve/
Du coup tu peux lancer ton find sans risques :
# find -P MonRep -type l -exec /bin/rm -f {} \;
Si
Bonjour,
Pour mon usage perso, j’ai écrit un petit script qui crée des liens symbolique
vers des fichiers dans un répertoire donné.
Mais j’aimerais que ce script me propose de supprimer les liens symboliques
déjà existants dans ce répertoire.
rm -f *
ou
unlik
Ca risque de supprimer des
54 matches
Mail list logo
