[arch-general] Mirror not updating
Anyone have contact info for the rit.edu mirror? It doesn't appear to have been updated since June 30. Thanks, DR
Am Donnerstag, den 09.07.2009, 09:27 -0400 schrieb David Rosenstrauch:
Anyone have contact info for the rit.edu mirror? It doesn't appear to have been updated since June 30.
I have contacted on Tuesday all mirror admin from the affected US/CA/EU mirrors, which are not synced and have all the same lastsync time. Only CA mirror http://mirror.twilightlair.net/arch is synced again from this block. I'll write a mail tomorrow again i nothing happens.
Thanks,
DR
Gerhard "gerbra"
Gerhard Brauer wrote:
Am Donnerstag, den 09.07.2009, 09:27 -0400 schrieb David Rosenstrauch:
Anyone have contact info for the rit.edu mirror? It doesn't appear to have been updated since June 30.
I have contacted on Tuesday all mirror admin from the affected US/CA/EU mirrors, which are not synced and have all the same lastsync time.
Only CA mirror http://mirror.twilightlair.net/arch is synced again from this block. I'll write a mail tomorrow again i nothing happens.
Thanks,
DR
Gerhard "gerbra"
Thanks much for the update! Just wondering: any way we could post status on a web page somewhere on the last time each mirror has synched? (And, for bonus points, maybe a 1-line status comment for each, where someone could post a message indicating what the status is of any issues that mirror is having.) Thanks again, DR
David Rosenstrauch wrote:
Gerhard Brauer wrote:
Am Donnerstag, den 09.07.2009, 09:27 -0400 schrieb David Rosenstrauch:
Anyone have contact info for the rit.edu mirror? It doesn't appear to have been updated since June 30.
I have contacted on Tuesday all mirror admin from the affected US/CA/EU mirrors, which are not synced and have all the same lastsync time.
Only CA mirror http://mirror.twilightlair.net/arch is synced again from this block. I'll write a mail tomorrow again i nothing happens.
Thanks,
DR
Gerhard "gerbra"
Thanks much for the update!
Just wondering: any way we could post status on a web page somewhere on the last time each mirror has synched? (And, for bonus points, maybe a 1-line status comment for each, where someone could post a message indicating what the status is of any issues that mirror is having.)
Allan McRae wrote:
Yes - exactly such as that! :-) Thanks much! Didn't even know that page existed. DR
On Thu, 09 Jul 2009 11:54:43 -0400 David Rosenstrauch <darose@darose.net> wrote:
Allan McRae wrote:
Yes - exactly such as that! :-)
Thanks much! Didn't even know that page existed.
DR
Maybe we should link to it from the main page or host it on archlinux.org if it's not too much work to migrate it (on the long term i want mirrorbrain) Dieter
Am Donnerstag, den 09.07.2009, 11:54 -0400 schrieb David Rosenstrauch:
Allan McRae wrote:
Yes - exactly such as that! :-)
Thanks much! Didn't even know that page existed.
You also could easy check a mirror with this script: --------------- #!/bin/sh # # Test Arch Linux Mirror status # Parameter: URL to test (full path to Arch Linux dir on mirror) # 2008/06/10 Gerhard Brauer <gerbra@archlinux.de> # ARCHES="i686 x86_64" REPOS="core extra community" echo echo "Mirror-URL: $1" echo "Last timestamp from rsync.archlinux.org (updated each hour)" echo "------------------------------------------------------------" for arch in ${ARCHES}; do for repo in ${REPOS}; do echo -e -n "$arch-$repo:\t" date +"%x %X" -u -d @$(wget -q -O - $1/$repo/os/$arch/lastsync) done done --------------- ex.: sh /tmp/mt.sh ftp://mirror.rit.edu/archlinux shows you (in UTC) the lastsync time. Means: this mirror has last synced to his upstream between the displayed timestap and displayed timestamp + 1 hour. To see the time according to your timezone, remove the -u parameter on date call.
DR
Gerhard "gerbra"
Am Donnerstag, den 09.07.2009, 19:17 +0200 schrieb Gerhard Brauer:
You also could easy check a mirror with this script:
Got an idea (hehe!).... Could we add such a check into pacman? So pacman could warn if current used mirror was outdated, or a commandline option to check the user prefered mirror. Gerhard "gerbra"
On Thu, Jul 9, 2009 at 13:44, Gerhard Brauer<gerhard.brauer@web.de> wrote:
Am Donnerstag, den 09.07.2009, 19:17 +0200 schrieb Gerhard Brauer:
You also could easy check a mirror with this script: Could we add such a check into pacman?
I don't think that's really needed. We shouldn't have any consistantly outdated mirrors, and if we do, they should be either marked as such or removed from the mirrorlist.
Perhaps not needed, but could be useful, more folks complaining generally = faster action on the part of a mirror admin (like yours truely)... although, if someone comes back from vacation to an inbox full of 300 "YOUR MIRROR IS OUTDATED" messages, they might be understandably unhappy. Might be nice to know as an end-user since one could switch off the mirror for a while.. mhm that part could even be made automagic. Cheers, Lee Burton lburton@mrow.org 301 910 0246 ----- Original Message ----- From: "Daenyth Blank" <daenyth+arch@gmail.com> To: "General Discusson about Arch Linux" <arch-general@archlinux.org> Sent: Thursday, July 9, 2009 1:59:09 PM GMT -05:00 US/Canada Eastern Subject: Re: [arch-general] Mirror not updating On Thu, Jul 9, 2009 at 13:44, Gerhard Brauer<gerhard.brauer@web.de> wrote:
Am Donnerstag, den 09.07.2009, 19:17 +0200 schrieb Gerhard Brauer:
You also could easy check a mirror with this script: Could we add such a check into pacman?
I don't think that's really needed. We shouldn't have any consistantly outdated mirrors, and if we do, they should be either marked as such or removed from the mirrorlist.
On Thu, Jul 9, 2009 at 14:28, Lee R. Burton<lburton@mrow.org> wrote:
Perhaps not needed, but could be useful, more folks complaining generally = faster action on the part of a mirror admin (like yours truely)... although, if someone comes back from vacation to an inbox full of 300 "YOUR MIRROR IS OUTDATED" messages, they might be understandably unhappy. Might be nice to know as an end-user since one could switch off the mirror for a while.. mhm that part could even be made automagic.
I still disagree. pacman is a package manager, not a mirror maintenance tool. An external script, or perhaps yaourt would be a better home for it.
On Thu-2009/07/09-19:17 Gerhard Brauer wrote:
for arch in ${ARCHES}; do for repo in ${REPOS}; do echo -e -n "$arch-$repo:\t" date +"%x %X" -u -d @$(wget -q -O - $1/$repo/os/$arch/lastsync) done done
please don't post anything like this: apart from being barely comprehendable, it is _unsafe_! you are using _outside info_ in a shell script _without validation_! it poses the risk of privilege escalation! and don't say security issues should be handled by remote admins! how about: # uses bash features shopt -s extglob iam="${0##*/}" tmp="" ex=0 tmpfile="${TMPDIR:-/tmp}/${iam}.tmp" wget="/usr/bin/wget -q" # risk: race rm -rf "${tmpfile}" && touch "${tmpfile}" || exit 9 for arch in ${ARCHES}; do for repo in ${REPOS}; do # risk: backquote execution, better use unpriv script ${wget} -O "${tmpfile}" "${1}/${repo}/os/${arch}/lastsync" || { ex=$? echo "${iam}: $1/${repo}/os/$arch/lastsync wget exits: ${ex}" continue } tmp="$(< ${tmpfile})" # remove all punctuation characters, check for numbers tmp="${tmp//[[:punct:]]}" case ".${tmp}" in .+([[:digit:]])) ;; # ok *) echo "${iam}: $1/${repo}/os/$arch/lastsync not number: ${tmp}" continue ;; esac echo -e -n "${arch}-${repo}:\t" date +"%x %X" -u -d "@${tmp}" done done not much longer, but a little safer. the least one should do in this situation. clemens
On Thursday 09 July 2009 17:50:50 David Rosenstrauch wrote:
any way we could post status on a web page somewhere on the last time each mirror has synched
There is https://www.archlinux.de/?page=MirrorStatus You can sort the list by last sync time etc.. There is also a list with current problems at the bottom. Its updated every hour and the average stats take the last two weeks into accout. -- Pierre Schmitz, http://users.archlinux.de/~pierre
I noticed this in my typical routine when installing AUR packages. 'makepkg -sic' is the typical command I use, and most of the time if dependencies are installed before building sudo doesn't time out before the install - meaning I do not have to re-enter a password for installing the package itself. This leaves a window where any time during the build process a command could have been executed with sudo and it would have went through without my knowledge. I do realize that it should be up to the user to validate all of the content, i.e. make sure everything is 'clean', but I thought I might bring it up for discussion.
On Thu, Jul 9, 2009 at 1:55 PM, Square<toolman33@gmail.com> wrote:
I noticed this in my typical routine when installing AUR packages. 'makepkg -sic' is the typical command I use, and most of the time if dependencies are installed before building sudo doesn't time out before the install - meaning I do not have to re-enter a password for installing the package itself. This leaves a window where any time during the build process a command could have been executed with sudo and it would have went through without my knowledge.
I do realize that it should be up to the user to validate all of the content, i.e. make sure everything is 'clean', but I thought I might bring it up for discussion.
This is up to you to control. You can change the timeout in /etc/sudoers by using the "password_timeout" (or is it "passwd_timeout"?) option.
Aaron Griffin schrieb:
On Thu, Jul 9, 2009 at 1:55 PM, Square<toolman33@gmail.com> wrote:
I noticed this in my typical routine when installing AUR packages. 'makepkg -sic' is the typical command I use, and most of the time if dependencies are installed before building sudo doesn't time out before the install - meaning I do not have to re-enter a password for installing the package itself. This leaves a window where any time during the build process a command could have been executed with sudo and it would have went through without my knowledge.
I do realize that it should be up to the user to validate all of the content, i.e. make sure everything is 'clean', but I thought I might bring it up for discussion.
This is up to you to control. You can change the timeout in /etc/sudoers by using the "password_timeout" (or is it "passwd_timeout"?) option.
I agree. The question is not about makepkg security, but about sudo security. And frankly, sudo is a security desaster in its default configuration.
On Thu, Jul 9, 2009 at 3:37 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
On Thu, Jul 9, 2009 at 1:55 PM, Square<toolman33@gmail.com> wrote:
I noticed this in my typical routine when installing AUR packages. 'makepkg -sic' is the typical command I use, and most of the time if dependencies are installed before building sudo doesn't time out before the install - meaning I do not have to re-enter a password for installing the package itself. This leaves a window where any time during the build process a command could have been executed with sudo and it would have went through without my knowledge.
I do realize that it should be up to the user to validate all of the content, i.e. make sure everything is 'clean', but I thought I might bring it up for discussion.
This is up to you to control. You can change the timeout in /etc/sudoers by using the "password_timeout" (or is it "passwd_timeout"?) option.
I agree. The question is not about makepkg security, but about sudo security. And frankly, sudo is a security desaster in its default configuration.
Any suggestions for changing / shipping a better default config file? I know little about the security implications of this, but I think we should ship a decent default if possible.
Aaron Griffin schrieb:
I agree. The question is not about makepkg security, but about sudo security. And frankly, sudo is a security desaster in its default configuration.
Any suggestions for changing / shipping a better default config file? I know little about the security implications of this, but I think we should ship a decent default if possible.
Our policy is usually to ship whatever upstream ships. IMO, a good default would be to set sudo to require the root password (not the user password) and not cache any passwords at all. Also, I think instead of using sudo in makepkg, we should use su by default (with an option to enable sudo). su always has a good default configuration requiring the root password (it's also possible to set it to allow password-less su in the pam configuration, but everyone who does that is crazy anyway).
On Fri, Jul 10, 2009 at 3:01 AM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
I agree. The question is not about makepkg security, but about sudo security. And frankly, sudo is a security desaster in its default configuration.
Any suggestions for changing / shipping a better default config file? I know little about the security implications of this, but I think we should ship a decent default if possible.
Our policy is usually to ship whatever upstream ships.
Not always - there has always been the "sane defaults" clause. We ship lots of config files and additional config files that upstream packages do not contain. Shipping and changing config files has nothing to do with "vanilla" because it's how the application was intended to work. Besides that, I like your ideas here... but perhaps we should move them to the pacman-dev list?
Aaron Griffin wrote:
On Fri, Jul 10, 2009 at 3:01 AM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
I agree. The question is not about makepkg security, but about sudo security. And frankly, sudo is a security desaster in its default configuration.
Any suggestions for changing / shipping a better default config file? I know little about the security implications of this, but I think we should ship a decent default if possible.
Our policy is usually to ship whatever upstream ships.
Not always - there has always been the "sane defaults" clause. We ship lots of config files and additional config files that upstream packages do not contain. Shipping and changing config files has nothing to do with "vanilla" because it's how the application was intended to work.
The default sudo config is quite sane and secure... I believe it gives no-one rights to use sudo. Any lessening of security is purely the administrators responsibility. Allan
Our policy is usually to ship whatever upstream ships. IMO, a good default would be to set sudo to require the root password (not the user password) and not cache any passwords at all. I strongly disagree with this. That's a disaster on a multiuser system. It purposely does *not* require the root password so that a user is responsible for only their own password, and so that you can
On Fri, Jul 10, 2009 at 04:01, Thomas Bächler<thomas@archlinux.org> wrote: limit their usage of superuser powers to only specific commands.
Also, I think instead of using sudo in makepkg, we should use su by default (with an option to enable sudo). su always has a good default configuration requiring the root password (it's also possible to set it to allow password-less su in the pam configuration, but everyone who does that is crazy anyway).
I don't think that should really be the default, personally. Sudo has been fine, I don't know of anyone having an actual issue with misuse.
On Fri, Jul 10, 2009 at 12:00:47PM -0400, Daenyth Blank wrote:
I don't think that should really be the default, personally. Sudo has been fine, I don't know of anyone having an actual issue with misuse.
I agree with the idea that it should be up to the user to secure their system. I went ahead and made sudo timeout much quicker after realizing this. Your point, however, that people haven't run into any misuse is a double-edged sword. For one, it's great that we need not worry considering the community is very friendly rather than malicious. Then again, ignorance could be harmful if someone were to decide to create malicious content. I don't see a need to change anything as it is unless the changes provided are optional.
On Thu, Jul 09, 2009 at 03:00:49PM -0500, Aaron Griffin wrote:
On Thu, Jul 9, 2009 at 1:55 PM, Square<toolman33@gmail.com> wrote:
I noticed this in my typical routine when installing AUR packages. 'makepkg -sic' is the typical command I use, and most of the time if dependencies are installed before building sudo doesn't time out before the install - meaning I do not have to re-enter a password for installing the package itself. This leaves a window where any time during the build process a command could have been executed with sudo and it would have went through without my knowledge.
I do realize that it should be up to the user to validate all of the content, i.e. make sure everything is 'clean', but I thought I might bring it up for discussion.
This is up to you to control. You can change the timeout in /etc/sudoers by using the "password_timeout" (or is it "passwd_timeout"?) option.
A simple workaround could be a "sudo -k" after each sudo invocation in the makepkg script.
On Thu, Jul 9, 2009 at 20:25, Alessandro Doro<ordo.ad@gmail.com> wrote:
A simple workaround could be a "sudo -k" after each sudo invocation in the makepkg script.
I don't think there should be any such behavior added. All we do is follow the settings the user has established -- no more and no less. Let's not have our tools start second-guessing the users. We should always start with the assumption that the user is competant.
On Thu, Jul 09, 2009 at 08:45:26PM -0400, Daenyth Blank wrote:
On Thu, Jul 9, 2009 at 20:25, Alessandro Doro<ordo.ad@gmail.com> wrote:
A simple workaround could be a "sudo -k" after each sudo invocation in the makepkg script.
I don't think there should be any such behavior added. All we do is follow the settings the user has established -- no more and no less. Let's not have our tools start second-guessing the users. We should always start with the assumption that the user is competant.
Competent and informed: I don't see a warning about potential¹ security issue in makepkg(8). Moreover the description of the '-s' option doesn't talk about the way root privileges are acquired². At least the sudo prompt should be customized, or is the user supposed to read the source (read: the user should not second-guess the tool)? Anyway I'm for discouraging the use of sudo for admnistrative tasks. bye ¹ Really theoretical, assuming that the user: · read the PKGBUILD, · trust the package source. ² Ok, ok... we all know it is obviuos.
On Fri, Jul 10, 2009 at 11:39 AM, Alessandro Doro<ordo.ad@gmail.com> wrote:
¹ Really theoretical, assuming that the user: · read the PKGBUILD, · trust the package source.
Yeah... I think I'd be somewhat suspicious if I saw a PKGBUILD calling sudo. sudo -k wouldn't be very effective either. What if I run sudo elsewhere on my system during the build process, the hole is open again. As long as you're running an untrusted script on your system, there's infinitely many other possibilities. An rm -rf ~/* is pretty damaging and doesn't need sudo. Allesandro is spot on. James
participants (13)
-
Aaron Griffin
-
Alessandro Doro
-
Allan McRae
-
clemens fischer
-
Daenyth Blank
-
David Rosenstrauch
-
Dieter Plaetinck
-
Gerhard Brauer
-
James Rayner
-
Lee R. Burton
-
Pierre Schmitz
-
Square
-
Thomas Bächler