Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Eric Luehrsen]

On 05/15/2017 10:16 PM, Philip Prindeville wrote:
>> On May 12, 2017, at 6:02 AM, Edwin van Drunen  wrote:
>>
>> I understand that the vote is done amongst the developers, the people 
>> actually running the project, this makes sense.
>> But if the goal of the project is not only to keep yourself busy, but also 
>> to target a larger audience, it makes sense to base some decisions on 
>> "market research".
>> The name is very important for user perception and influences the audience 
>> you will reach.
>
>
> Maybe one person as the “user ombudsman” could be given a vote.
>
> I have no idea how such a person would be chosen, however.
>
> -Philip

An assigned vote might be a bit much. Mailing list banter like this 
could be useful advice, if it is observed carefully. A two-pass voting 
process with a comment period could help. Any organization should find a 
way to stay in touch with its patronage, whether its funds or volunteer 
labor.

-Eric
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Philip Prindeville]

> On May 12, 2017, at 6:02 AM, Edwin van Drunen  wrote:
> 
> I understand that the vote is done amongst the developers, the people 
> actually running the project, this makes sense.
> But if the goal of the project is not only to keep yourself busy, but also to 
> target a larger audience, it makes sense to base some decisions on "market 
> research".
> The name is very important for user perception and influences the audience 
> you will reach.


Maybe one person as the “user ombudsman” could be given a vote.

I have no idea how such a person would be chosen, however.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Eric Luehrsen]

On 05/15/2017 09:11 PM, Philip Prindeville wrote:
>> On May 11, 2017, at 10:09 PM, Eric Luehrsen  wrote:
>>
>> People don't like rules and that could be even more true with open
>> source work groups. However, a good set of _limited_ rules can make life
>> easier. You may focus on important work or joyful recreation while not
>> worrying about accidental trespasses.
>
>
> I can’t say I agree.
>
> Part of my past frustration with submissions to OpenWRT was that I was cited 
> “requirements” that needed to be satisfied before my PR’s could be merged.  
> Oftentimes these “requirements” weren’t written down anywhere else and didn’t 
> seem to be applied in a even-handed way.  These “requirements” occasionally 
> seemed more like individual preferences, and more than once I was told by one 
> person “You need to do things this way” only to be told I needed to do things 
> the exact opposite some time later by yet another person.
>
> That was a few years ago.  Lately things are marginally better, if noticeably 
> bandwidth-limited.
>
> In sort… I’d rather have the rules all called out and be out in the open, 
> thereby people can be assured that if they follow the rules they will have 
> met the requirements (ALL the requirements) for their PR’s to be merged 
> without having to watch the goal posts be moved…
>
> -Philip

I was referring to policy, procedure, organization, and behavior rules. 
The kind that once you accept them for the organization they keep you 
from stepping on each others toes.

Style guides and other work product detail rules are part in another 
subject. But again we can consider a similar concept of _limited_ and as 
you said _written_ rules. When they are unwritten, then some unpleasant 
individual can block your participation because, well, just because. If 
a group writes "these are seven submission requirements and the only 
seven," and they adhere to them, then it is much harder for an 
unpleasant individual to be arbitrary.

-Eric
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Philip Prindeville]

> On May 11, 2017, at 10:09 PM, Eric Luehrsen  wrote:
> 
> People don't like rules and that could be even more true with open 
> source work groups. However, a good set of _limited_ rules can make life 
> easier. You may focus on important work or joyful recreation while not 
> worrying about accidental trespasses.


I can’t say I agree.

Part of my past frustration with submissions to OpenWRT was that I was cited 
“requirements” that needed to be satisfied before my PR’s could be merged.  
Oftentimes these “requirements” weren’t written down anywhere else and didn’t 
seem to be applied in a even-handed way.  These “requirements” occasionally 
seemed more like individual preferences, and more than once I was told by one 
person “You need to do things this way” only to be told I needed to do things 
the exact opposite some time later by yet another person.

That was a few years ago.  Lately things are marginally better, if noticeably 
bandwidth-limited.

In sort… I’d rather have the rules all called out and be out in the open, 
thereby people can be assured that if they follow the rules they will have met 
the requirements (ALL the requirements) for their PR’s to be merged without 
having to watch the goal posts be moved…

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Eric Luehrsen]

On 15.05.2017 18:02, Val Kulkov wrote:
 > On 15 May 2017 at 11:46, Yousong Zhou  wrote:
 >> On 15 May 2017 at 23:29, Val Kulkov  wrote:
 >>> Yousong, perhaps I was not clear. What I am suggesting is to change
 >>> the auto-allocation to start from 1000 rather than from 100 (1000 is
 >>> just a suggestion, it could be anything else that is high enough), and
 >>> to have a convention to allocate the 1-999 range to the services.
 >>> Then, the allocation of uid/gid for any new package would be subject
 >>> to review and approval by the reviewers. We would have to maintain a
 >>> Wiki page listing all uids and gids that have already been taken,
 >>> FreeBSD-style.
 >>>
 >>> This way, we would only have to reallocate uids and gids for packages
 >>> that are 1000 and higher. The other packages that use uids and gids in
 >>> the 1-999 range would not be affected, other than the packages that
 >>> already have a conflict (icecast and postfix, for example).
 >>>
 >> I guess the the user, group related utility functions are intended for
 >> use by services only.  Adding users and groups for multi-user
 >> interactive is just not the use case for  LEDE (this is only personal
 >> opinion and not in the book).
 >>
 >> The suggestion is to let default_postinst to auto-allocation uid/gid
 >> from 1 or 100, and let useradd/useradd/groupadd/addgroup to start from
 >> whatever high number.
 >>
 >> If we can automate things without separately maintaining a list of any
 >> kind and manual cooperation across groups of people, we should prefer
 >> that
 >>
 >>  yousong
 > I agree that not depending on the manual cooperation across groups of
 > people would be ideal. However, updating 35+ packages to use the
 > auto-allocation mechanism is not an easy undertaking. Besides, some of
 > the packages might actually rely on particular numeric uid/gid's - we
 > don't know until we run tests with these packages.
 >
 > Here is another suggestion. make menuconfig might collect all USERID:=
 > strings from all packages and produce a list of uids and gids that
 > have been taken so that the auto-allocation mechanism will stay away
 > from these uids/gids. Such lists will likely be fairly compact, taking
 > perhaps less than 500 bytes. This will (1) avoid conflicts between
 > packages, (2) avoid the need to re-do the uid/gid allocation for 35+
 > packages, and (3) not require manual cooperation between groups of
 > people in the future.

I know for Unbound package the hard coded GID/UID doesn't functionally 
matter. Many other packages seem to be the same. You need a non-root 
user to drop down to. You also don't want one common other user or else 
"nobody:nogroup" becomes the new root (in a way). It may not be so 
difficult to get cooperation.

Trouble occurs supporting LEDE vs OpenWrt split. Some people want to SDK 
only a few latest add on packages, but keep their preferred stable base. 
15.01.1 doesn't support install UID/GID assignment. There are other 
divergences. Compatibility across the split generates non-ideal design 
choices. It makes maintaining optional packages more and more difficult. 
Once that matter is closed, this symptom effect may all but solve itself.

- Eric

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] kernel: update 17.01 kernel 4.4 to 4.4.68

[Stijn Segers]

Bump the 17.01 tree kernel to 4.4.68. Trunk 4.4 and 17.01 4.4 have diverged, 
talked this
through with jow, he was okay with a clean diff against 17.01 and not a 
backported trunk
patch.

The following patches were applied upstream:

 062-[1-6]-MIPS-* series
 042-0004-mtd-bcm47xxpart-fix-parsing-first-block

Reintroduced lantiq/patches-4.4/0050-MIPS-Lantiq-Fix-cascaded-IRQ-setup, as 
it was incorrectly included upstream thus dropped from LEDE, but subsequently
reverted upstream.

Compile-tested on: ar71xx, ramips/mt7621, x86/64.

Run-tested on: ar71xx, ramips/mt7621.

Signed-off-by: Stijn Segers 
---
 include/kernel-version.mk  |   4 +-
 .../patches-4.4/910-unaligned_access_hacks.patch   |   4 +-
 .../patches-4.4/0029-Add-dwc_otg-driver.patch  |   2 +-
 ...le-CONFIG_MEMCG-but-leave-it-disabled-due.patch |   4 +-
 ...Restore-IO-APIC-irq_chip-retrigger-callba.patch |  46 
 .../brcm63xx/patches-4.4/577-board_VH4032N.patch   |   6 +-
 ...m47xxpart-don-t-fail-because-of-bit-flips.patch |   4 +-
 ...part-fix-parsing-first-block-after-aligne.patch |  40 ---
 .../062-01-MIPS-Introduce-irq_stack.patch  |  70 -
 ...2-MIPS-Stack-unwinding-while-on-IRQ-stack.patch |  42 
 ...hange-28-to-thread_info-if-coming-from-us.patch |  48 -
 ...IPS-Switch-to-the-irq_stack-in-interrupts.patch | 116 -
 ...05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch |  21 
 ...ack-Fix-erroneous-jal-to-plat_irq_dispatc.patch |  35 ---
 .../patches-4.4/630-packet_socket_type.patch   |   4 +-
 .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch |  22 ++--
 ...jecting-with-source-address-failed-policy.patch |  22 ++--
 ...dwc3-Validate-the-maximum_speed-parameter.patch |   2 +-
 .../096-08-usb-dwc3-remove-num_event_buffers.patch |  12 +--
 .../096-09-usb-dwc3-drop-ev_buffs-array.patch  |   4 +-
 ...b-phy-Add-Qualcomm-DWC3-HS-SS-PHY-drivers.patch |   2 +-
 .../linux/lantiq/patches-4.4/0047-irq-fixes.patch  |   4 +-
 .../0050-MIPS-Lantiq-Fix-cascaded-IRQ-setup.patch  |  87 
 ...mtd-backport-v4.7-0day-patches-from-Boris.patch |   4 +-
 ...mtd-backport-v4.7-0day-patches-from-Boris.patch |   4 +-
 .../100-clk-sunxi-add-dram-gates-support.patch |   2 +-
 .../107-clk-sunxi-add-h3-usbphy-clocks.patch   |   2 +-
 .../110-clk-sunxi-add-ve-for-sun457i.patch |   4 +-
 28 files changed, 143 insertions(+), 474 deletions(-)
 delete mode 100644 
target/linux/brcm2708/patches-4.4/0577-x86-ioapic-Restore-IO-APIC-irq_chip-retrigger-callba.patch
 delete mode 100644 
target/linux/generic/patches-4.4/042-0004-mtd-bcm47xxpart-fix-parsing-first-block-after-aligne.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-01-MIPS-Introduce-irq_stack.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-02-MIPS-Stack-unwinding-while-on-IRQ-stack.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-03-MIPS-Only-change-28-to-thread_info-if-coming-from-us.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-04-MIPS-Switch-to-the-irq_stack-in-interrupts.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-06-MIPS-IRQ-Stack-Fix-erroneous-jal-to-plat_irq_dispatc.patch
 create mode 100644 
target/linux/lantiq/patches-4.4/0050-MIPS-Lantiq-Fix-cascaded-IRQ-setup.patch

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index b56bb237d9..9f30cf2088 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,10 +3,10 @@
 LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .61
+LINUX_VERSION-4.4 = .68
 
 LINUX_KERNEL_HASH-3.18.43 = 
1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.61 = 
30dee7164615ad8184eba4ea6f4906b3ceb2fe462a8a4a929c8e9aab8d4a31da
+LINUX_KERNEL_HASH-4.4.68 = 
3231c1822ed552877d12c96ba32944ddc017d346fab9c6dd4f31c3e9f026bdbf
 
 ifdef KERNEL_PATCHVER
   LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git a/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch 
b/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
index e7df08b0d2..7e3ba4c8d5 100644
--- a/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
+++ b/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
@@ -310,7 +310,7 @@
if (t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK)
 --- a/net/ipv6/ip6_tunnel.c
 +++ b/net/ipv6/ip6_tunnel.c
-@@ -1407,7 +1407,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
+@@ -1409,7 +1409,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
  
dsfield = ipv6_get_dsfield(ipv6h);
if (t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS)
@@ -621,7 +621,7 @@
 * XXX skbs on the gro_list have all been parsed and pulled
 --- a/include/net/addrconf.h
 +++ b/include/net/addrconf.h

[LEDE-DEV] [PATCH] igmpproxy: Set logopts to "-d" to prevent spamming the system log

[Dmitry Tunin]

This option redirects the igmpproxy to STDERR instead of system log.
Without this option the system log is unusable because igmpproxy warns about
every SSDP package recieved from wan.

Signed-off-by: Dmitry Tunin 
---
 package/network/services/igmpproxy/files/igmpproxy.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/igmpproxy/files/igmpproxy.init 
b/package/network/services/igmpproxy/files/igmpproxy.init
index 9f4e51a..394958c 100644
--- a/package/network/services/igmpproxy/files/igmpproxy.init
+++ b/package/network/services/igmpproxy/files/igmpproxy.init
@@ -103,7 +103,7 @@ service_triggers() {
 start_service() {
has_upstream=
netdevs=
-   logopts=
+   logopts="-d"
config_load igmpproxy
 
config_foreach igmp_header igmpproxy
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Daniel Golle]

On Mon, May 15, 2017 at 10:59:55PM +0800, Yousong Zhou wrote:
> On 15 May 2017 at 22:41, Val Kulkov  wrote:
> > The auto-allocation of uid/gid emulates useradd/groupadd, picking the
> > first unused uid/gid starting from 100. This works quite well on its
> > own, but there are about three dozen packages in the packages repo
> > that come with hardcoded uid/gid's:
> >
> > find -L package/ -name Makefile -exec grep 'USERID:=' {} \;
> >
> > produces 35 or so lines indicating the assignment of hardcoded uids and 
> > gids.
> >
> > At present, if someone installs five packages that use the
> > auto-allocation mechanism, uids 100-105 will be taken by the
> > auto-allocation mechanism (101 is already taken by 'network'). After
> > that, attempting to install the 'avahi' package will result in a
> > conflict:
> >USERID:=avahi=105:avahi=105
> >
> > IMO such conflicts can and must be avoided.
> 
> Exactly!
> 
> > Perhaps the easiest way to
> > avoid such conflicts is to maintain a list of uid/gid allocation (a la
> > FreeBSD) and have a policy in place regarding the allocation of new
> > uid/gid's. For example, the 1-999 range may be reserved for services
> > and starting from 1000 for regular users. IMO this is an important
> > step forward in creating a resilient package space environment.
> >
> 
> Maintain a big list and package it in every built firmware so that
> auto-allocation  can skip them?  It's overkill I guess.
> 
> How about just converting existing hardcoded uid/gid assignment to use
> only auto-allocation method and also drop the USERID=un=uid:gn=gid
> support from default_postinst.  Will this break something
> significantly?

Yes, it will break at least one place I know where I rely on hardcoded
GIDs being adjecent for their use with the 'owner' match in iptables,
see
https://github.com/openwrt/packages/blob/master/net/gnunet/files/gnunet-gns.defaults#L36

However, differentiating DNS traffic generated by 'special DNS users'
(such as DNS servers, caches, ...) from regular DNS traffic is truly
the only application I can think of right now, I never needed to
rely on hard-coded GIDs before. If anyone knows a good and
non-intrusive alternative to the above, I'd be happy to switch to
auto-allocated UIDs/GIDs.


> 
> yousong
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Alberto Bursi]

On 05/15/2017 07:29 PM, Tobias Welz wrote:
>
> If not, there would be the need to do some post-processing after 
> restore to somehow fix gids/uids to make everything work again; but it 
> will be an extra level of complexity. 

uhm, I might say something very noobish, but...

are all packages groups/uids added  to /etc/passwd which is a static 
text file?

Would it make sense to backup/restore it on sysupgrade (if it isn't 
already in the whitelist)?

That way services get random uids but they are preserved across 
sysupgrades in a very easy way.

-Alberto
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Val Kulkov]

On 15 May 2017 at 11:46, Yousong Zhou  wrote:
> On 15 May 2017 at 23:29, Val Kulkov  wrote:
>> Yousong, perhaps I was not clear. What I am suggesting is to change
>> the auto-allocation to start from 1000 rather than from 100 (1000 is
>> just a suggestion, it could be anything else that is high enough), and
>> to have a convention to allocate the 1-999 range to the services.
>> Then, the allocation of uid/gid for any new package would be subject
>> to review and approval by the reviewers. We would have to maintain a
>> Wiki page listing all uids and gids that have already been taken,
>> FreeBSD-style.
>>
>> This way, we would only have to reallocate uids and gids for packages
>> that are 1000 and higher. The other packages that use uids and gids in
>> the 1-999 range would not be affected, other than the packages that
>> already have a conflict (icecast and postfix, for example).
>>
>
> I guess the the user, group related utility functions are intended for
> use by services only.  Adding users and groups for multi-user
> interactive is just not the use case for  LEDE (this is only personal
> opinion and not in the book).
>
> The suggestion is to let default_postinst to auto-allocation uid/gid
> from 1 or 100, and let useradd/useradd/groupadd/addgroup to start from
> whatever high number.
>
> If we can automate things without separately maintaining a list of any
> kind and manual cooperation across groups of people, we should prefer
> that ;)
>
> yousong

I agree that not depending on the manual cooperation across groups of
people would be ideal. However, updating 35+ packages to use the
auto-allocation mechanism is not an easy undertaking. Besides, some of
the packages might actually rely on particular numeric uid/gid's - we
don't know until we run tests with these packages.

Here is another suggestion. make menuconfig might collect all USERID:=
strings from all packages and produce a list of uids and gids that
have been taken so that the auto-allocation mechanism will stay away
from these uids/gids. Such lists will likely be fairly compact, taking
perhaps less than 500 bytes. This will (1) avoid conflicts between
packages, (2) avoid the need to re-do the uid/gid allocation for 35+
packages, and (3) not require manual cooperation between groups of
people in the future.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Yousong Zhou]

On 15 May 2017 at 23:29, Val Kulkov  wrote:
> Yousong, perhaps I was not clear. What I am suggesting is to change
> the auto-allocation to start from 1000 rather than from 100 (1000 is
> just a suggestion, it could be anything else that is high enough), and
> to have a convention to allocate the 1-999 range to the services.
> Then, the allocation of uid/gid for any new package would be subject
> to review and approval by the reviewers. We would have to maintain a
> Wiki page listing all uids and gids that have already been taken,
> FreeBSD-style.
>
> This way, we would only have to reallocate uids and gids for packages
> that are 1000 and higher. The other packages that use uids and gids in
> the 1-999 range would not be affected, other than the packages that
> already have a conflict (icecast and postfix, for example).
>

I guess the the user, group related utility functions are intended for
use by services only.  Adding users and groups for multi-user
interactive is just not the use case for  LEDE (this is only personal
opinion and not in the book).

The suggestion is to let default_postinst to auto-allocation uid/gid
from 1 or 100, and let useradd/useradd/groupadd/addgroup to start from
whatever high number.

If we can automate things without separately maintaining a list of any
kind and manual cooperation across groups of people, we should prefer
that ;)

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Val Kulkov]

On 15 May 2017 at 11:12, Yousong Zhou  wrote:
> On 15 May 2017 at 23:04, Val Kulkov  wrote:
>> On 15 May 2017 at 10:59, Yousong Zhou  wrote:
>>> On 15 May 2017 at 22:41, Val Kulkov  wrote:
 The auto-allocation of uid/gid emulates useradd/groupadd, picking the
 first unused uid/gid starting from 100. This works quite well on its
 own, but there are about three dozen packages in the packages repo
 that come with hardcoded uid/gid's:

 find -L package/ -name Makefile -exec grep 'USERID:=' {} \;

 produces 35 or so lines indicating the assignment of hardcoded uids and 
 gids.

 At present, if someone installs five packages that use the
 auto-allocation mechanism, uids 100-105 will be taken by the
 auto-allocation mechanism (101 is already taken by 'network'). After
 that, attempting to install the 'avahi' package will result in a
 conflict:
USERID:=avahi=105:avahi=105

 IMO such conflicts can and must be avoided.
>>>
>>> Exactly!
>>>
 Perhaps the easiest way to
 avoid such conflicts is to maintain a list of uid/gid allocation (a la
 FreeBSD) and have a policy in place regarding the allocation of new
 uid/gid's. For example, the 1-999 range may be reserved for services
 and starting from 1000 for regular users. IMO this is an important
 step forward in creating a resilient package space environment.

>>>
>>> Maintain a big list and package it in every built firmware so that
>>> auto-allocation  can skip them?  It's overkill I guess.
>>>
>>> How about just converting existing hardcoded uid/gid assignment to use
>>> only auto-allocation method and also drop the USERID=un=uid:gn=gid
>>> support from default_postinst.  Will this break something
>>> significantly?
>>>
>>> yousong
>>
>> I was thinking about a Wiki page which would be consulted by reviewers
>> each time a new package is considered for the addition to the packages
>> repo. This way, there is no need to include a big table into the
>> firmware, and there is no need to change the existing assignment
>> unless there is already a conflict.
>
> 1. Hardcoded uid 105 is not better than auto-allocated uid 101 and
> only slightly better than auto-allocated uid 1001
> 2. If the list is not present in the device at allocation time, I
> guess the situation you presented above cannot be avoided
>
> yousong

Yousong, perhaps I was not clear. What I am suggesting is to change
the auto-allocation to start from 1000 rather than from 100 (1000 is
just a suggestion, it could be anything else that is high enough), and
to have a convention to allocate the 1-999 range to the services.
Then, the allocation of uid/gid for any new package would be subject
to review and approval by the reviewers. We would have to maintain a
Wiki page listing all uids and gids that have already been taken,
FreeBSD-style.

This way, we would only have to reallocate uids and gids for packages
that are 1000 and higher. The other packages that use uids and gids in
the 1-999 range would not be affected, other than the packages that
already have a conflict (icecast and postfix, for example).

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Yousong Zhou]

On 15 May 2017 at 23:04, Val Kulkov  wrote:
> On 15 May 2017 at 10:59, Yousong Zhou  wrote:
>> On 15 May 2017 at 22:41, Val Kulkov  wrote:
>>> The auto-allocation of uid/gid emulates useradd/groupadd, picking the
>>> first unused uid/gid starting from 100. This works quite well on its
>>> own, but there are about three dozen packages in the packages repo
>>> that come with hardcoded uid/gid's:
>>>
>>> find -L package/ -name Makefile -exec grep 'USERID:=' {} \;
>>>
>>> produces 35 or so lines indicating the assignment of hardcoded uids and 
>>> gids.
>>>
>>> At present, if someone installs five packages that use the
>>> auto-allocation mechanism, uids 100-105 will be taken by the
>>> auto-allocation mechanism (101 is already taken by 'network'). After
>>> that, attempting to install the 'avahi' package will result in a
>>> conflict:
>>>USERID:=avahi=105:avahi=105
>>>
>>> IMO such conflicts can and must be avoided.
>>
>> Exactly!
>>
>>> Perhaps the easiest way to
>>> avoid such conflicts is to maintain a list of uid/gid allocation (a la
>>> FreeBSD) and have a policy in place regarding the allocation of new
>>> uid/gid's. For example, the 1-999 range may be reserved for services
>>> and starting from 1000 for regular users. IMO this is an important
>>> step forward in creating a resilient package space environment.
>>>
>>
>> Maintain a big list and package it in every built firmware so that
>> auto-allocation  can skip them?  It's overkill I guess.
>>
>> How about just converting existing hardcoded uid/gid assignment to use
>> only auto-allocation method and also drop the USERID=un=uid:gn=gid
>> support from default_postinst.  Will this break something
>> significantly?
>>
>> yousong
>
> I was thinking about a Wiki page which would be consulted by reviewers
> each time a new package is considered for the addition to the packages
> repo. This way, there is no need to include a big table into the
> firmware, and there is no need to change the existing assignment
> unless there is already a conflict.

1. Hardcoded uid 105 is not better than auto-allocated uid 101 and
only slightly better than auto-allocated uid 1001
2. If the list is not present in the device at allocation time, I
guess the situation you presented above cannot be avoided

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Val Kulkov]

On 15 May 2017 at 10:59, Yousong Zhou  wrote:
> On 15 May 2017 at 22:41, Val Kulkov  wrote:
>> The auto-allocation of uid/gid emulates useradd/groupadd, picking the
>> first unused uid/gid starting from 100. This works quite well on its
>> own, but there are about three dozen packages in the packages repo
>> that come with hardcoded uid/gid's:
>>
>> find -L package/ -name Makefile -exec grep 'USERID:=' {} \;
>>
>> produces 35 or so lines indicating the assignment of hardcoded uids and gids.
>>
>> At present, if someone installs five packages that use the
>> auto-allocation mechanism, uids 100-105 will be taken by the
>> auto-allocation mechanism (101 is already taken by 'network'). After
>> that, attempting to install the 'avahi' package will result in a
>> conflict:
>>USERID:=avahi=105:avahi=105
>>
>> IMO such conflicts can and must be avoided.
>
> Exactly!
>
>> Perhaps the easiest way to
>> avoid such conflicts is to maintain a list of uid/gid allocation (a la
>> FreeBSD) and have a policy in place regarding the allocation of new
>> uid/gid's. For example, the 1-999 range may be reserved for services
>> and starting from 1000 for regular users. IMO this is an important
>> step forward in creating a resilient package space environment.
>>
>
> Maintain a big list and package it in every built firmware so that
> auto-allocation  can skip them?  It's overkill I guess.
>
> How about just converting existing hardcoded uid/gid assignment to use
> only auto-allocation method and also drop the USERID=un=uid:gn=gid
> support from default_postinst.  Will this break something
> significantly?
>
> yousong

I was thinking about a Wiki page which would be consulted by reviewers
each time a new package is considered for the addition to the packages
repo. This way, there is no need to include a big table into the
firmware, and there is no need to change the existing assignment
unless there is already a conflict.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Yousong Zhou]

On 15 May 2017 at 22:41, Val Kulkov  wrote:
> The auto-allocation of uid/gid emulates useradd/groupadd, picking the
> first unused uid/gid starting from 100. This works quite well on its
> own, but there are about three dozen packages in the packages repo
> that come with hardcoded uid/gid's:
>
> find -L package/ -name Makefile -exec grep 'USERID:=' {} \;
>
> produces 35 or so lines indicating the assignment of hardcoded uids and gids.
>
> At present, if someone installs five packages that use the
> auto-allocation mechanism, uids 100-105 will be taken by the
> auto-allocation mechanism (101 is already taken by 'network'). After
> that, attempting to install the 'avahi' package will result in a
> conflict:
>USERID:=avahi=105:avahi=105
>
> IMO such conflicts can and must be avoided.

Exactly!

> Perhaps the easiest way to
> avoid such conflicts is to maintain a list of uid/gid allocation (a la
> FreeBSD) and have a policy in place regarding the allocation of new
> uid/gid's. For example, the 1-999 range may be reserved for services
> and starting from 1000 for regular users. IMO this is an important
> step forward in creating a resilient package space environment.
>

Maintain a big list and package it in every built firmware so that
auto-allocation  can skip them?  It's overkill I guess.

How about just converting existing hardcoded uid/gid assignment to use
only auto-allocation method and also drop the USERID=un=uid:gn=gid
support from default_postinst.  Will this break something
significantly?

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Val Kulkov]

On 15 May 2017 at 09:46, Yousong Zhou  wrote:
> On 15 May 2017 at 21:07, Val Kulkov  wrote:
>> On 15 May 2017 at 02:30, Alexandru Ardelean  wrote:
>>> On Sun, May 14, 2017 at 3:59 AM, Daniel Golle  wrote:
 Hi Val,

 On Sat, May 13, 2017 at 06:23:29PM -0400, Val Kulkov wrote:
> Is there any convention on the use of uid and gid when creating new
> users or groups? Can someone point me to it, if it exists?
>
> I noticed that two packages, icecast and postfix, compete for the same 
> uid=87:
>
> icecast's Makefile:
>   USERID:=icecast=87:icecast=87
>
> postfix's postfix.init:
>   user_exists postfix || user_add postfix 87

 This looks wrong to me (user_add in the init script)...

>
> There may be more packages competing for the same uid/gid's, I have
> not fully researched it.
>
> I am preparing a new package, opendkim, which should be run as a
> non-privileged user. For this,
> USERID:=opendkim=:opendkim= seems appropriate,
> but what numbers should I assign?

 I run into this issue before and believe that we should have a wiki
 page which allows registering static UIDs/GIDs at least for the
 packages which actually need that (ie. if a specific UID or GID is
 referenced in other packages, or scripts like firewall rules, ...).
 Grep'ing for USERID allows to automatically generate that list based
 on the currently available packages very easily.

 Examples from elsewhere for inspiration:

 FreeBSD got those lists
 https://svnweb.freebsd.org/ports/head/UIDs?view=markup
 https://svnweb.freebsd.org/ports/head/GIDs?view=markup

 linuxfromscratch got a much smaller list for essential/system UIDs/GIDs
 http://linuxfromscratch.org/blfs/view/svn/postlfs/users.html


 Cheers

>>>
>>> Just woke up from the weekend.
>>> I recommend trying this out [based on lldpd] :
>>> https://github.com/lede-project/source/blob/master/package/network/services/lldpd/Makefile#L35
>>> We use lldpd and this seems to work ; lldpd does some priv separation.
>>>
>>> Alex
>>
>> Alexandru, the USERID:= construct works really well, but my question
>> was about the convention to avoid conflicts while picking numbers for
>> new UID and GID. For example, icecast and postfix both use 87 for a
>> new UID they create.
>>
>> I think the links to FreeBSD's UID and GID lists that Daniel provided
>> are indeed an excellent source of inspiration. We should a Wiki page
>> with a similar content.
>>
>
> If it's only about allocation of uid/gid without collision, then the
> default_postinst() func will just do that [1], e.g.
> USERID:=icecast:icecast
>
> I do not know of any service checking non-root username of its
> effective uid/gid and quit if they fail expectation.  The other thing
> is that if we allow auto-allocation with default_postinst and preserve
> /etc/{passwd,group} across sysupgrade, then the global allocation of
> uid/gid may not work out because those slots may already be taken up
> by the auto-allocation happen prior of time...
>
>  [1] https://github.com/openwrt/packages/pull/3150#discussion_r83354888

The auto-allocation of uid/gid emulates useradd/groupadd, picking the
first unused uid/gid starting from 100. This works quite well on its
own, but there are about three dozen packages in the packages repo
that come with hardcoded uid/gid's:

find -L package/ -name Makefile -exec grep 'USERID:=' {} \;

produces 35 or so lines indicating the assignment of hardcoded uids and gids.

At present, if someone installs five packages that use the
auto-allocation mechanism, uids 100-105 will be taken by the
auto-allocation mechanism (101 is already taken by 'network'). After
that, attempting to install the 'avahi' package will result in a
conflict:
   USERID:=avahi=105:avahi=105

IMO such conflicts can and must be avoided. Perhaps the easiest way to
avoid such conflicts is to maintain a list of uid/gid allocation (a la
FreeBSD) and have a policy in place regarding the allocation of new
uid/gid's. For example, the 1-999 range may be reserved for services
and starting from 1000 for regular users. IMO this is an important
step forward in creating a resilient package space environment.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] kernel: bump to 4.4.68

[Kevin Darbyshire-Bryant]

Refresh patches. A number of patches have landed upstream & hence are no
longer required locally:

062-[1-6]-MIPS-* series
042-0004-mtd-bcm47xxpart-fix-parsing-first-block

Reintroduced lantiq/patches-4.4/0050-MIPS-Lantiq-Fix-cascaded-IRQ-setup
as it was incorrectly included upstream thus dropped from LEDE.
As it has now been reverted upstream it needs to be included again for
LEDE.

Run tested ar71xx Archer C7 v2

Signed-off-by: Kevin Darbyshire-Bryant 
---
 include/kernel-version.mk  |   4 +-
 .../525-MIPS-ath79-enable-qca-usb-quirks.patch |   8 +-
 .../601-MIPS-ath79-add-more-register-defines.patch |   4 +-
 .../patches-4.4/609-MIPS-ath79-ap136-fixes.patch   |  14 +--
 .../patches-4.4/910-unaligned_access_hacks.patch   |   4 +-
 .../ar71xx/patches-4.4/930-chipidea-pullup.patch   |  10 +-
 ...m47xxpart-don-t-fail-because-of-bit-flips.patch |   4 +-
 ...part-fix-parsing-first-block-after-aligne.patch |  40 ---
 .../062-01-MIPS-Introduce-irq_stack.patch  |  70 -
 ...2-MIPS-Stack-unwinding-while-on-IRQ-stack.patch |  42 
 ...hange-28-to-thread_info-if-coming-from-us.patch |  48 -
 ...IPS-Switch-to-the-irq_stack-in-interrupts.patch | 116 -
 ...05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch |  21 
 ...ack-Fix-erroneous-jal-to-plat_irq_dispatc.patch |  35 ---
 .../patches-4.4/630-packet_socket_type.patch   |   4 +-
 .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch |  22 ++--
 ...jecting-with-source-address-failed-policy.patch |  22 ++--
 .../linux/lantiq/patches-4.4/0047-irq-fixes.patch  |   4 +-
 .../0050-MIPS-Lantiq-Fix-cascaded-IRQ-setup.patch  |  87 
 ...mtd-backport-v4.7-0day-patches-from-Boris.patch |   4 +-
 .../100-clk-sunxi-add-dram-gates-support.patch |   2 +-
 .../107-clk-sunxi-add-h3-usbphy-clocks.patch   |   2 +-
 .../110-clk-sunxi-add-ve-for-sun457i.patch |   4 +-
 23 files changed, 143 insertions(+), 428 deletions(-)
 delete mode 100644 
target/linux/generic/patches-4.4/042-0004-mtd-bcm47xxpart-fix-parsing-first-block-after-aligne.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-01-MIPS-Introduce-irq_stack.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-02-MIPS-Stack-unwinding-while-on-IRQ-stack.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-03-MIPS-Only-change-28-to-thread_info-if-coming-from-us.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-04-MIPS-Switch-to-the-irq_stack-in-interrupts.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch
 delete mode 100644 
target/linux/generic/patches-4.4/062-06-MIPS-IRQ-Stack-Fix-erroneous-jal-to-plat_irq_dispatc.patch
 create mode 100644 
target/linux/lantiq/patches-4.4/0050-MIPS-Lantiq-Fix-cascaded-IRQ-setup.patch

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 0a58a45..a77a44e 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,11 +3,11 @@
 LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .61
+LINUX_VERSION-4.4 = .68
 LINUX_VERSION-4.9 = .20
 
 LINUX_KERNEL_HASH-3.18.43 = 
1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.61 = 
30dee7164615ad8184eba4ea6f4906b3ceb2fe462a8a4a929c8e9aab8d4a31da
+LINUX_KERNEL_HASH-4.4.68 = 
35d490c1518d6b3cbe849ae0d23f4a02d656e5b03c800d060fbda3b39a3190d3
 LINUX_KERNEL_HASH-4.9.20 = 
48660806dd32fb8dcbcf5932291bf6cc7d29240070372230871e0f56fea81341
 
 ifdef KERNEL_PATCHVER
diff --git 
a/target/linux/ar71xx/patches-4.4/525-MIPS-ath79-enable-qca-usb-quirks.patch 
b/target/linux/ar71xx/patches-4.4/525-MIPS-ath79-enable-qca-usb-quirks.patch
index 61b6b4e..0e33674 100644
--- a/target/linux/ar71xx/patches-4.4/525-MIPS-ath79-enable-qca-usb-quirks.patch
+++ b/target/linux/ar71xx/patches-4.4/525-MIPS-ath79-enable-qca-usb-quirks.patch
@@ -29,9 +29,7 @@
 -  u32 bootstrap;
 +  void __iomem *phy_reg;
 +  u32 t;
- 
--  bootstrap = ath79_reset_rr(AR934X_RESET_REG_BOOTSTRAP);
--  if (bootstrap & AR934X_BOOTSTRAP_USB_MODE_DEVICE)
++
 +  phy_reg = ioremap(base, 4);
 +  if (!phy_reg)
 +  return;
@@ -43,7 +41,9 @@
 +
 +  iounmap(phy_reg);
 +}
-+
+ 
+-  bootstrap = ath79_reset_rr(AR934X_RESET_REG_BOOTSTRAP);
+-  if (bootstrap & AR934X_BOOTSTRAP_USB_MODE_DEVICE)
 +static void ar934x_usb_reset_notifier(struct platform_device *pdev)
 +{
 +  if (pdev->id != -1)
diff --git 
a/target/linux/ar71xx/patches-4.4/601-MIPS-ath79-add-more-register-defines.patch
 
b/target/linux/ar71xx/patches-4.4/601-MIPS-ath79-add-more-register-defines.patch
index 03ca106..e4d82ac 100644
--- 
a/target/linux/ar71xx/patches-4.4/601-MIPS-ath79-add-more-register-defines.patch
+++ 
b/target/linux/ar71xx/patches-4.4/601-MIPS-ath79-add-more-register-defines.patch
@@ -155,7 +155,7 @@
 +#define AR934X_RESET_LUT  BIT(2)
 +#define 

Re: [LEDE-DEV] convention on uid/gid for packages

[Yousong Zhou]

On 15 May 2017 at 21:07, Val Kulkov  wrote:
> On 15 May 2017 at 02:30, Alexandru Ardelean  wrote:
>> On Sun, May 14, 2017 at 3:59 AM, Daniel Golle  wrote:
>>> Hi Val,
>>>
>>> On Sat, May 13, 2017 at 06:23:29PM -0400, Val Kulkov wrote:
 Is there any convention on the use of uid and gid when creating new
 users or groups? Can someone point me to it, if it exists?

 I noticed that two packages, icecast and postfix, compete for the same 
 uid=87:

 icecast's Makefile:
   USERID:=icecast=87:icecast=87

 postfix's postfix.init:
   user_exists postfix || user_add postfix 87
>>>
>>> This looks wrong to me (user_add in the init script)...
>>>

 There may be more packages competing for the same uid/gid's, I have
 not fully researched it.

 I am preparing a new package, opendkim, which should be run as a
 non-privileged user. For this,
 USERID:=opendkim=:opendkim= seems appropriate,
 but what numbers should I assign?
>>>
>>> I run into this issue before and believe that we should have a wiki
>>> page which allows registering static UIDs/GIDs at least for the
>>> packages which actually need that (ie. if a specific UID or GID is
>>> referenced in other packages, or scripts like firewall rules, ...).
>>> Grep'ing for USERID allows to automatically generate that list based
>>> on the currently available packages very easily.
>>>
>>> Examples from elsewhere for inspiration:
>>>
>>> FreeBSD got those lists
>>> https://svnweb.freebsd.org/ports/head/UIDs?view=markup
>>> https://svnweb.freebsd.org/ports/head/GIDs?view=markup
>>>
>>> linuxfromscratch got a much smaller list for essential/system UIDs/GIDs
>>> http://linuxfromscratch.org/blfs/view/svn/postlfs/users.html
>>>
>>>
>>> Cheers
>>>
>>
>> Just woke up from the weekend.
>> I recommend trying this out [based on lldpd] :
>> https://github.com/lede-project/source/blob/master/package/network/services/lldpd/Makefile#L35
>> We use lldpd and this seems to work ; lldpd does some priv separation.
>>
>> Alex
>
> Alexandru, the USERID:= construct works really well, but my question
> was about the convention to avoid conflicts while picking numbers for
> new UID and GID. For example, icecast and postfix both use 87 for a
> new UID they create.
>
> I think the links to FreeBSD's UID and GID lists that Daniel provided
> are indeed an excellent source of inspiration. We should a Wiki page
> with a similar content.
>

If it's only about allocation of uid/gid without collision, then the
default_postinst() func will just do that [1], e.g.
USERID:=icecast:icecast

I do not know of any service checking non-root username of its
effective uid/gid and quit if they fail expectation.  The other thing
is that if we allow auto-allocation with default_postinst and preserve
/etc/{passwd,group} across sysupgrade, then the global allocation of
uid/gid may not work out because those slots may already be taken up
by the auto-allocation happen prior of time...

 [1] https://github.com/openwrt/packages/pull/3150#discussion_r83354888

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1

[Ram Chandra Jangir]

Thanks Chris Blake,

>First off, thank you very much for this patch and your work on the ipq40xx 
>platform. I have been doing more testing, and it seems that some of the pins 
>in pinctl are not defined to the correct function.
>This is what I am currently seeing on the board:

> [1.278649] ipq4019-pinctrl 100.pinctrl: invalid group "gpio57"
>for function "qpic_pad"
> [1.279841] ipq4019-pinctrl 100.pinctrl: invalid group "gpio58"
>for function "qpic_pad"
> [1.288214] ipq4019-pinctrl 100.pinctrl: invalid group "gpio59"
>for function "qpic_pad"
> [1.296508] ipq4019-pinctrl 100.pinctrl: invalid group "gpio60"
>for function "qpic_pad"
> [1.304905] ipq4019-pinctrl 100.pinctrl: invalid group "gpio64"
>for function "qpic_pad"
> [1.313190] ipq4019-pinctrl 100.pinctrl: invalid group "gpio65"
>for function "qpic_pad"
> [1.321522] ipq4019-pinctrl 100.pinctrl: invalid group "gpio66"
>for function "qpic_pad"
> [1.329856] ipq4019-pinctrl 100.pinctrl: invalid group "gpio67"
>for function "qpic_pad"
> [1.338190] ipq4019-pinctrl 100.pinctrl: invalid group "gpio68"
>for function "qpic_pad"

>With that said, NAND still inits and works. I was also able to clear up the 
>errors by fixing the groups for each GPIO in my DTS with the help of 
>Christian. Example of this is at https://pastebin.com/rQDY3z9c.

>Is this something specific with my board, or some other variation with your 
>patch? I am new to this arch so please excuse me if any of this is noobish. :)

Pinctrl driver has proper definitions & values  for  respective GPIO's  in the 
patch and I did not observe such issues in IPQ4019 DK01, DK04 and other 
variants of Dakota boards, they work fine as expected.

Thanks,
Ram
 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Val Kulkov]

On 15 May 2017 at 02:30, Alexandru Ardelean  wrote:
> On Sun, May 14, 2017 at 3:59 AM, Daniel Golle  wrote:
>> Hi Val,
>>
>> On Sat, May 13, 2017 at 06:23:29PM -0400, Val Kulkov wrote:
>>> Is there any convention on the use of uid and gid when creating new
>>> users or groups? Can someone point me to it, if it exists?
>>>
>>> I noticed that two packages, icecast and postfix, compete for the same 
>>> uid=87:
>>>
>>> icecast's Makefile:
>>>   USERID:=icecast=87:icecast=87
>>>
>>> postfix's postfix.init:
>>>   user_exists postfix || user_add postfix 87
>>
>> This looks wrong to me (user_add in the init script)...
>>
>>>
>>> There may be more packages competing for the same uid/gid's, I have
>>> not fully researched it.
>>>
>>> I am preparing a new package, opendkim, which should be run as a
>>> non-privileged user. For this,
>>> USERID:=opendkim=:opendkim= seems appropriate,
>>> but what numbers should I assign?
>>
>> I run into this issue before and believe that we should have a wiki
>> page which allows registering static UIDs/GIDs at least for the
>> packages which actually need that (ie. if a specific UID or GID is
>> referenced in other packages, or scripts like firewall rules, ...).
>> Grep'ing for USERID allows to automatically generate that list based
>> on the currently available packages very easily.
>>
>> Examples from elsewhere for inspiration:
>>
>> FreeBSD got those lists
>> https://svnweb.freebsd.org/ports/head/UIDs?view=markup
>> https://svnweb.freebsd.org/ports/head/GIDs?view=markup
>>
>> linuxfromscratch got a much smaller list for essential/system UIDs/GIDs
>> http://linuxfromscratch.org/blfs/view/svn/postlfs/users.html
>>
>>
>> Cheers
>>
>
> Just woke up from the weekend.
> I recommend trying this out [based on lldpd] :
> https://github.com/lede-project/source/blob/master/package/network/services/lldpd/Makefile#L35
> We use lldpd and this seems to work ; lldpd does some priv separation.
>
> Alex

Alexandru, the USERID:= construct works really well, but my question
was about the convention to avoid conflicts while picking numbers for
new UID and GID. For example, icecast and postfix both use 87 for a
new UID they create.

I think the links to FreeBSD's UID and GID lists that Daniel provided
are indeed an excellent source of inspiration. We should a Wiki page
with a similar content.

>
>>
>> Daniel
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] kernel: update kernel 4.9 to 4.9.28

[Koen Vandeputte]

- Refresh all patches
- Removed upstreamed
- Adapted 1

Compile tested on: bcm53xx, cns3xxx, imx6
Run tested on: cns3xxx & imx6

Signed-off-by: Koen Vandeputte 
---

3rd & final attempt to bump the kernel.
I would be very grateful if more people could test it on different targets.


 include/kernel-version.mk  |   4 +-
 .../802-usb-xhci-force-msi-renesas-xhci.patch  |   2 +-
 ...stmmac-Disable-frame-filtering-completely.patch |   4 +-
 ...stmmac-Disable-frame-filtering-completely.patch |   4 +-
 ...X-Add-back-handler-ignoring-external-impr.patch |  75 
 ...-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch |  41 ---
 ...ave-host-bridge-window-resource-in-struct.patch | 131 -
 ...-add-support-for-performing-fake-doorbell.patch |  10 +-
 .../patches-4.9/905-BCM53573-minor-hacks.patch |   2 +-
 .../patches-4.9/950-0031-Add-dwc_otg-driver.patch  |   2 +-
 ...-thermal-driver-for-reporting-core-temper.patch |   2 +-
 ...le-CONFIG_MEMCG-but-leave-it-disabled-due.patch |   4 +-
 ...-Fix-hang-for-writing-messages-larger-tha.patch |  90 --
 .../031-ubifs-fix-RENAME_WHITEOUT-support.patch|  25 
 .../040-01-MIPS-Introduce-irq_stack.patch  |  70 ---
 ...2-MIPS-Stack-unwinding-while-on-IRQ-stack.patch |  42 ---
 ...hange-28-to-thread_info-if-coming-from-us.patch |  48 
 ...IPS-Switch-to-the-irq_stack-in-interrupts.patch | 116 --
 ...05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch |  21 
 ...ack-Fix-erroneous-jal-to-plat_irq_dispatc.patch |  35 --
 ...part-fix-parsing-first-block-after-aligne.patch |  40 ---
 .../patches-4.9/630-packet_socket_type.patch   |   4 +-
 .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch |  22 ++--
 ...jecting-with-source-address-failed-policy.patch |  22 ++--
 .../generic/patches-4.9/701-phy_extension.patch|   2 +-
 .../710-phy-add-mdio_register_board_info.patch |   2 +-
 .../810-pci_disable_common_quirks.patch|   6 +-
 .../generic/patches-4.9/904-debloat_dma_buf.patch  |   2 +-
 ...sdhc-imx-increase-the-pad-I-O-drive-stren.patch |  42 ---
 .../patches-4.9/0032-phy-add-qcom-dwc3-phy.patch   |   2 +-
 ...om-use-scm_call-to-route-GPIO-irq-to-Apps.patch |   2 +-
 .../0008-MIPS-lantiq-backport-old-timer-code.patch |   2 +-
 .../patches-4.9/0026-NET-multi-phy-support.patch   |   6 +-
 ...-lantiq-wifi-and-ethernet-eeprom-handling.patch |   2 +-
 .../patches-4.9/0001-NET-multi-phy-support.patch   |   6 +-
 ...soc-mediatek-Add-MT2701-power-dt-bindings.patch |  10 +-
 ...k-Refine-scpsys-to-support-multiple-platf.patch |  19 ++-
 ...015-soc-mediatek-Add-MT2701-scpsys-driver.patch |  12 +-
 .../patches-4.9/0071-pwm-add-pwm-mediatek.patch|  16 +--
 .../linux/mediatek/patches-4.9/0083-mfd-led3.patch |   4 +-
 .../mediatek/patches-4.9/0085-pmic-led0.patch  |   3 -
 .../mediatek/patches-4.9/0086-pmic-led1.patch  |   4 +-
 .../mediatek/patches-4.9/0087-pmic-led2.patch  |  10 +-
 .../mediatek/patches-4.9/0088-pmic-led3.patch  |   4 +-
 target/linux/mediatek/patches-4.9/0091-dsa1.patch  |   3 -
 .../0091-net-next-mediatek-fix-DQL-support.patch   |   6 +-
 target/linux/mediatek/patches-4.9/0092-dsa2.patch  |  23 +---
 target/linux/mediatek/patches-4.9/0092-dsa3.patch  |   6 +-
 target/linux/mediatek/patches-4.9/0092-dsa4.patch  |   4 +-
 target/linux/mediatek/patches-4.9/0092-dsa5.patch  |  16 +--
 .../mediatek/patches-4.9/0093-dsa-compat.patch |  18 +--
 .../mediatek/patches-4.9/0094-net-affinity.patch   |  12 +-
 target/linux/mediatek/patches-4.9/0095-ephy.patch  |  12 +-
 .../mediatek/patches-4.9/0096-dsa-multi-cpu.patch  |  30 ++---
 .../mediatek/patches-4.9/0097-dsa-mt7530.patch |   6 +-
 ...erpc-85xx-add-gpio-keys-to-of-match-table.patch |   2 +-
 .../100-powerpc-85xx-tl-wdr4900-v1-support.patch   |   4 +-
 ...ovide-a-hook-for-link-up-link-down-events.patch |  18 +--
 ...-phy-move-phy-MMD-accessors-to-phy-core.c.patch |   2 +-
 ...oid-setting-unsupported-EEE-advertisments.patch |   2 +-
 ...tart-phy-autonegotiation-after-EEE-advert.patch |   2 +-
 ...-phy-allow-EEE-with-SGMII-interface-modes.patch |   2 +-
 ...hook-up-clause-45-autonegotiation-restart.patch |   2 +-
 ...-phy-export-phy_start_machine-for-phylink.patch |   2 +-
 .../patches-4.9/0034-NET-multi-phy-support.patch   |   6 +-
 .../patches-4.9/200-rt3883-fix-pinctrl-typo.patch  |  21 
 66 files changed, 141 insertions(+), 1030 deletions(-)
 delete mode 100644 
target/linux/bcm53xx/patches-4.9/031-ARM-BCM5301X-Add-back-handler-ignoring-external-impr.patch
 delete mode 100644 
target/linux/bcm53xx/patches-4.9/033-0013-ARM-dts-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch
 delete mode 100644 
target/linux/bcm53xx/patches-4.9/089-PCI-iproc-Save-host-bridge-window-resource-in-struct.patch
 delete mode 100644 
target/linux/brcm2708/patches-4.9/950-0106-i2c-bcm2835-Fix-hang-for-writing-messages-larger-tha.patch
 delete mode 

Re: [LEDE-DEV] [PATCH v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Bastian Bittorf]

* Bastian Bittorf  [15.05.2017 09:27]:
> > +   [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> 
> thanks for the patch!
> 
> please test for 'bool_true' not for 1

sorry for the noise, this is already normalized by
config_get_bool() - so testing for 0 or 1 is fine.

bye, bastian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Bastian Bittorf]

* Paul Oranje  [15.05.2017 09:08]:
> fixes FS#785
> v1: write /tmp/resolv.conf also when nosolv is true
> v2: also change guard in dnsmasq_stop() routine
> 
> Signed-off-by: Paul Oranje 
> ---
>  package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 30fec7a4ee..c7506ed4ea 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -947,7 +947,7 @@ dnsmasq_start()
>   echo >> $CONFIGFILE_TMP
>   mv -f $CONFIGFILE_TMP $CONFIGFILE
>  
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {

thanks for the patch!

please test for 'bool_true' not for 1
also: should'nt it be 'noresolv'?

bye, bastian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1

[Ram Chandra Jangir]

>Hello Ram,

On Thursday, May 11, 2017 8:39:46 PM CEST Christian Lamparter wrote:
> On Thursday, May 11, 2017 10:15:58 PM CEST Ram Chandra Jangir wrote:
> > I added nand pinmux in https://patchwork.ozlabs.org/patch/761243/ , 
> > Could you please try with this, if it helps you.
> Thanks, I'll forward it to Chris Blake. He can test it once he 
> returns. I'll let you know how it turned out.

>Chris reported:
>[1.40] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
>[1.007580] nand: AMD/Spansion S34ML01G2
>[1.014146] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
>[1.018135] 11 ofpart partitions found on MTD device qcom_nand.0
>[1.025449] Creating 11 MTD partitions on "qcom_nand.0":

>so, it's working now.
Great and thank you...  

Thanks,
Ram




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] convention on uid/gid for packages

[Alexandru Ardelean]

On Sun, May 14, 2017 at 3:59 AM, Daniel Golle  wrote:
> Hi Val,
>
> On Sat, May 13, 2017 at 06:23:29PM -0400, Val Kulkov wrote:
>> Is there any convention on the use of uid and gid when creating new
>> users or groups? Can someone point me to it, if it exists?
>>
>> I noticed that two packages, icecast and postfix, compete for the same 
>> uid=87:
>>
>> icecast's Makefile:
>>   USERID:=icecast=87:icecast=87
>>
>> postfix's postfix.init:
>>   user_exists postfix || user_add postfix 87
>
> This looks wrong to me (user_add in the init script)...
>
>>
>> There may be more packages competing for the same uid/gid's, I have
>> not fully researched it.
>>
>> I am preparing a new package, opendkim, which should be run as a
>> non-privileged user. For this,
>> USERID:=opendkim=:opendkim= seems appropriate,
>> but what numbers should I assign?
>
> I run into this issue before and believe that we should have a wiki
> page which allows registering static UIDs/GIDs at least for the
> packages which actually need that (ie. if a specific UID or GID is
> referenced in other packages, or scripts like firewall rules, ...).
> Grep'ing for USERID allows to automatically generate that list based
> on the currently available packages very easily.
>
> Examples from elsewhere for inspiration:
>
> FreeBSD got those lists
> https://svnweb.freebsd.org/ports/head/UIDs?view=markup
> https://svnweb.freebsd.org/ports/head/GIDs?view=markup
>
> linuxfromscratch got a much smaller list for essential/system UIDs/GIDs
> http://linuxfromscratch.org/blfs/view/svn/postlfs/users.html
>
>
> Cheers
>

Just woke up from the weekend.
I recommend trying this out [based on lldpd] :
https://github.com/lede-project/source/blob/master/package/network/services/lldpd/Makefile#L35
We use lldpd and this seems to work ; lldpd does some priv separation.

Alex

>
> Daniel
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev