Re: update pms driver
Did this go in? If not, looks fine and works for me, sorry for the delay testing this one got lost in my inbox. On Tue, Oct 19, 2010 at 08:44:47PM +0600, Alexandr Shadchin wrote: > On Tue, Oct 19, 2010 at 07:01:24AM -0400, Kenneth R Westerback wrote: > > > > Done. Next? :-). > > > > Ken > > Clean function pms_change_state(): > 1) removed unused code (#if 0) > 2) return to a uniform style ( return (fobar); ) > 3) small code optimization > > No functional change. > > -- > Alexandr Shadchin > > Index: pms.c > === > RCS file: /cvs/src/sys/dev/pckbc/pms.c,v > retrieving revision 1.11 > diff -u -p -r1.11 pms.c > --- pms.c 19 Oct 2010 11:00:50 - 1.11 > +++ pms.c 19 Oct 2010 14:27:49 - > @@ -203,7 +203,8 @@ pms_change_state(struct pms_softc *sc, i > switch (newstate) { > case PMS_STATE_ENABLED: > if (sc->sc_state == PMS_STATE_ENABLED) > - return EBUSY; > + return (EBUSY); > + > sc->inputstate = 0; > sc->oldbuttons = 0; > > @@ -221,48 +222,21 @@ pms_change_state(struct pms_softc *sc, i > res = pms_cmd(sc, cmd, 1, NULL, 0); > if (res) > printf("pms_enable: command error\n"); > -#if 0 > - { > - u_char scmd[2]; > - > - scmd[0] = PMS_SET_RES; > - scmd[1] = 3; /* 8 counts/mm */ > - res = pckbc_enqueue_cmd(sc->sc_kbctag, sc->sc_kbcslot, > scmd, > - 2, 0, 1, 0); > - if (res) > - printf("pms_enable: setup error1 (%d)\n", res); > - > - scmd[0] = PMS_SET_SCALE21; > - res = pckbc_enqueue_cmd(sc->sc_kbctag, sc->sc_kbcslot, > scmd, > - 1, 0, 1, 0); > - if (res) > - printf("pms_enable: setup error2 (%d)\n", res); > - > - scmd[0] = PMS_SET_SAMPLE; > - scmd[1] = 100; /* 100 samples/sec */ > - res = pckbc_enqueue_cmd(sc->sc_kbctag, sc->sc_kbcslot, > scmd, > - 2, 0, 1, 0); > - if (res) > - printf("pms_enable: setup error3 (%d)\n", res); > - } > -#endif > - sc->sc_state = newstate; > - sc->poll = 0; > break; > case PMS_STATE_DISABLED: > - > - /* FALLTHROUGH */ > case PMS_STATE_SUSPENDED: > cmd[0] = PMS_DEV_DISABLE; > res = pms_cmd(sc, cmd, 1, NULL, 0); > if (res) > printf("pms_disable: command error\n"); > pckbc_slot_enable(sc->sc_kbctag, sc->sc_kbcslot, 0); > - sc->sc_state = newstate; > - sc->poll = (newstate == PMS_STATE_SUSPENDED) ? 1 : 0; > break; > } > - return 0; > + > + sc->sc_state = newstate; > + sc->poll = (newstate == PMS_STATE_SUSPENDED) ? 1 : 0; > + > + return (0); > } > > int
Re: testing rthreads
On Mon, 25 Oct 2010, Vladimir Kirillov wrote: > I've been trying to test rthreads and have hit some weird races > using simple tests: ... > I get this segfault almost always: > > #0 pthread_exit (retval=0x0) at /usr/src/lib/librthread/rthread.c:223 > 223 for (clfn = thread->cleanup_fns; clfn; ) { ... > Looks like some stupid race with two threads exiting at almost same > time? Any ideas on tracking it down? The problem was actually introduced during the c2k10 hackathon, where I changed getthrid() to always add THREAD_PID_OFFSET to the proc's real pid (which closes a race for pthread_kill)...but failed to teach fork1() to do that too. The patch at bottom fixes this in my testing. (I wasn't seeing this myself becauswe I'm normally running a severely hacked librthread that uses the platform's per-thread register to implement pthread_self() instead of having to walk the thread list. Sorry folks. Time to get this stuff committed...) > By the way, is such gdb behaviour normal? Does it need any additional > patching before being useful to debug software using rthreads? Oh yes, it needs lots of work. I don't know if anyone had really looked closely at this yet. Philip Guenther Index: sys/kern/kern_fork.c === RCS file: /cvs/src/sys/kern/kern_fork.c,v retrieving revision 1.122 diff -u -p -r1.122 kern_fork.c --- sys/kern/kern_fork.c26 Jul 2010 01:56:27 - 1.122 +++ sys/kern/kern_fork.c30 Oct 2010 22:52:39 - @@ -480,7 +480,8 @@ fork1(struct proc *p1, int exitsig, int * marking us as parent via retval[1]. */ if (retval != NULL) { - retval[0] = p2->p_pid; + retval[0] = p2->p_pid + + (flags & FORK_THREAD ? THREAD_PID_OFFSET : 0); retval[1] = 0; } return (0);
Re: small nit in nsd.conf manpage.
Hi Janne, hi Jakob, Janne Johansson wrote on Sat, Oct 30, 2010 at 10:03:51PM +0200: > The word "slave" will not appear in the manpage when the nsd.conf > source looks like it does. OK schwarze@; but please make sure this is also sent upstream, ideally coordinated with the rest of the cleanup (Jakob?). This is indeed a manual formatting bug. It is not specific to OpenBSD. It happens with groff-1.15, groff-1.20 and mandoc. The point is that a single quote in column 1 is a macro control character, see here: $ mandoc -Tlint /usr/src/usr.sbin/nsd/nsd.conf.5 [...] /usr/src/usr.sbin/nsd/nsd.conf.5:349:2: ERROR: skipping unknown macro: unknown macro: 'Slave'. ... This is not the only ERROR in nsd.conf(5) causing information loss. The man(7) source code quality of the nsd documentation is very poor in general and far from meeting OpenBSD quality standards. This stuff is in dire need of cleanup, but of course the cleanup has to be fed back upstream. The page nsd.conf.5 alone yields eight ERRORs, at least three of which are very serious, and 161 WARNINGs on top of that, though most of the latter are just trailing whitespace. Yours, Ingo > Index: nsd.conf.5 > === > RCS file: /cvs/src/usr.sbin/nsd/nsd.conf.5,v > retrieving revision 1.2 > diff -u -r1.2 nsd.conf.5 > --- nsd.conf.5 1 Oct 2010 20:45:09 - 1.2 > +++ nsd.conf.5 30 Oct 2010 20:00:09 - > @@ -345,8 +345,7 @@ > file, which may have different security policies, can be split apart. > .SH "NSD CONFIGURATION FOR BIND9 HACKERS" > BIND9 is a name server implementation with its own configuration > -file format, named.conf(5). BIND9 types zones as 'Master' or > -'Slave'. > +file format, named.conf(5). BIND9 types zones as 'Master' or 'Slave'. > .SS "Slave zones" > For a slave zone, the master servers are listed. The master servers are > queried for zone data, and are listened to for update notifications.
Re: sync adduser with installer
On Fri, Oct 29, 2010 at 10:12 PM, Brynet wrote: > > I believe the real problem here is that you're allowing users on your > systems that are incapable of properly setting the group/world > permissions of their home directories. My employer lets a variety of people on their systems - they just want work to get done and don't know or care about this kind of thing. Don't you have this problem where you work? Seriously, putting everyone in the same 'users' group is like running all your daemons as 'nobody'. I can quote a stack of UNIX books that recommend against both (a couple examples are Secure Architectures with OpenBSD, the AbsoluteBSD books, and the ones I linked to above). They all talk about using 'adduser' and how per-user groups is the best option - which is why it is the default. Changing the default would invalidate a lot of documentation. > It's also a possibility that you are derelict in your duties as a > systems administrator. > > No cookies for you. This is tech@, not m...@. Daniel
Re: sync adduser with installer
On Fri, Oct 29, 2010 at 10:12 PM, Brynet wrote: > Daniel wrote: >> Same here. Really, I'm surprised that anyone is using the 'users' >> group at all these days, especially on OpenBSD. If all users are in >> the same group, group permissions are no different from world >> permissions. > > I believe the real problem here is that you're allowing users on your > systems that are incapable of properly setting the group/world > permissions of their home directories. You're right, I should have required new CS and physics students to defeat me in single CLI combat before they could take the courses that required group handling. > It's also a possibility that you are derelict in your duties as a > systems administrator. You're suggesting that selecting a default that reduces support calls and reduces user aggravation is a sign of *bad* systems administration practice? That's an interesting take on best practices. Philip Guenther
Abu Dhabi: Professional Proposal & Report Writing, Dt. 28 -29 November, 2010 Reg....
PROFESSIONAL PROPOSAL & REPORT WRITING (Informative, Persuasive, Clear & Professional) 28 â 29 November 2010 Abu Dhabi - UAE Download Brochure: PRW-Abu Dhabi(pdf format) Book Your Seat : RESERVE ME A SEAT _ _ ___ This 2-day Professional Report Writing, will provide you with the exact skills to write reports and proposals that are informative, persuasive, clear and professional. Take-away: Participants will receive a thumb-drive/CD with comprehensive training manual in PDF format. This will provide you with over 200 pages of comprehensively tested training material to guide you in your technical writing when you return to work. Course Facilitator: Tim North, Director â Scribe Consulting: âI've had very positive feedback after last week's course; seven people called to say they were using the techniques discussed! I thoroughly enjoyed it also and found it extremely helpful.â - Program Coordinator for a State Government department âThanks for your training input to the People Rich team in relation to effective reports and proposals. It provided us with an excellent framework to properly launch our work to market. Your time and expertise were greatly appreciated.â - Performance Consultant for an executive coaching company âTim, thank you for your valuable training session today. The information you imparted was above expectations and easy to digest.â - Senior Procurement Officer for an international engineering group You may bring samples of your reports to get on-site professional assessment and opinion from the trainer. - Download Brochure: Abu Dhabi(pdf format) - Donât forget to book your seat: RESERVE ME A SEAT - Click here for IN-HOUSE Proposal/Quotation: IN-HOUSE PROPOSAL Kind regards Mrs. Vishali Sr. Project Coordinator(Sales & Marketing) 360BSI (INDIA) Tel : +91-912360 Mobile : +91-9959327497 Fax:: +91-40-27125575 Email1: vish...@360bsi.com Email2: srini...@360bsi.com UPCOMING EVENTS Professional Proposal & Report Writing 28 - 29 November 2010, ABU DHABI - UAE http://www.360b si.com/brochuredownload/PRW-NOV-SRI.pdf ROOT CAUSE ANALYSIS (RCA) (for HSE/Process/QA/QC/Reliability) 31 OCT - 02 NOV 2010 GULF HOTEL BAHRAIN, MANAMA-BAHRAIN http://www.360b si.com/brochuredownload/RCA-BAH-SRI.pdf
small nit in nsd.conf manpage.
The word "slave" will not appear in the manpage when the nsd.conf source looks like it does. Patch here: Index: nsd.conf.5 === RCS file: /cvs/src/usr.sbin/nsd/nsd.conf.5,v retrieving revision 1.2 diff -u -r1.2 nsd.conf.5 --- nsd.conf.5 1 Oct 2010 20:45:09 - 1.2 +++ nsd.conf.5 30 Oct 2010 20:00:09 - @@ -345,8 +345,7 @@ file, which may have different security policies, can be split apart. .SH "NSD CONFIGURATION FOR BIND9 HACKERS" BIND9 is a name server implementation with its own configuration -file format, named.conf(5). BIND9 types zones as 'Master' or -'Slave'. +file format, named.conf(5). BIND9 types zones as 'Master' or 'Slave'. .SS "Slave zones" For a slave zone, the master servers are listed. The master servers are queried for zone data, and are listened to for update notifications. /jj@ -- To our sweethearts and wives. May they never meet. -- 19th century toast
Re: smtpd w/ async DNS
On Sat, Oct 30, 2010 at 07:26:00PM +0200, Peter J. Philipp wrote: > I had a look at the pack.c file where the DNS compression is being handled. > It looks good to me. But I have one concern that needs to be confirmed. > In function dname_expand() on lines: > > 54 ptr = 256 * (n & ~0xc0) + data[offset + 1]; > 55 if (ptr >= offset) > 56 return (-1); > > The pointer is checked against offset meaning that a compression loop can't > occur. This is good. However what happens if you have a DNS reply packet > with a name with two labels in it, one being a normal label of a name and the > second being a compression pointer that points back to the first label, > kinda like so.. > > [8]centroid[C0 back to 8] > > I'm worried it might go into an infinite loop or crash even. > > Perhaps it should check that it cannot go back to a label inside a dns name > that > is being parsed. You are totally right. The following patch should fix it. Thanks a lot. Eric. --- pack.c.orig Sat Oct 30 21:22:14 2010 +++ pack.c Sat Oct 30 21:22:06 2010 @@ -38,21 +38,21 @@ ssize_t dname_expand(const unsigned char *data, size_t len, size_t offset, size_t *newoffset, char *dst, size_t max) { - size_t n, count, end, ptr; + size_t n, count, end, ptr, start; ssize_t res; if (offset >= len) return (-1); res = 0; - end = offset; + end = start = offset; for(; (n = data[offset]); ) { if ((n & 0xc0) == 0xc0) { if (offset + 2 > len) return (-1); ptr = 256 * (n & ~0xc0) + data[offset + 1]; - if (ptr >= offset) + if (ptr >= start) return (-1); if (end < offset + 2) end = offset + 2; @@ -91,8 +91,9 @@ const char * dname_nthlabel(int n, const unsigned char *data, size_t len, size_t offset) { int i; - size_t c, ptr; + size_t c, ptr, start; + start = offset; for(i = 0;;) { c = data[offset]; if (c == 0) @@ -101,7 +102,7 @@ dname_nthlabel(int n, const unsigned char *data, size_ if (len < offset + 2) return (NULL); ptr = 256 * (c & ~0xc0) + data[offset + 1]; - if (ptr >= offset) + if (ptr >= start) return (NULL); offset = ptr; continue; @@ -117,14 +118,15 @@ dname_nthlabel(int n, const unsigned char *data, size_ ssize_t dname_count_labels(const unsigned char *data, size_t len, size_t offset) { - size_t c, n, ptr; + size_t c, n, ptr, start; + start = offset; for(n = 0; (c = data[offset]); ) { if ((c & 0xc0) == 0xc0) { if (len < offset + 2) return (-1); ptr = 256 * (c & ~0xc0) + data[offset + 1]; - if (ptr >= offset) + if (ptr >= start) return (-1); offset = ptr; continue;
Re: smtpd w/ async DNS
On Sat, Oct 30, 2010 at 05:28:42PM +0200, Gilles Chehade wrote: > It was a typo indeed, tarball has been updated and also contains a fix for > a crash experienced by todd@ when using "relay via" > > Gilles I had a look at the pack.c file where the DNS compression is being handled. It looks good to me. But I have one concern that needs to be confirmed. In function dname_expand() on lines: 54 ptr = 256 * (n & ~0xc0) + data[offset + 1]; 55 if (ptr >= offset) 56 return (-1); The pointer is checked against offset meaning that a compression loop can't occur. This is good. However what happens if you have a DNS reply packet with a name with two labels in it, one being a normal label of a name and the second being a compression pointer that points back to the first label, kinda like so.. [8]centroid[C0 back to 8] I'm worried it might go into an infinite loop or crash even. Perhaps it should check that it cannot go back to a label inside a dns name that is being parsed. Otherwise rockin' code! I don't understand it all but the little I do it looks really high quality! -peter
Re: smtpd w/ async DNS
On 10/30/10 17:23, Peter J. Philipp wrote: On Sat, Oct 30, 2010 at 04:55:36PM +0200, Gilles Chehade wrote: Hi tech@, A new tarball with all reported issues fixed is available at: http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz smtpd now catches changes in /etc/resolv.conf and should work fine with inet6 records. I have done some stress testing here and it's been stable. asr has also been improved by eric@ who cleaned up code, fixed some bugs and added tcp support, honors the family keyword in /etc/resolv.conf. Please test fast and report issues so that we can move to the next features ;-) Gilles Hi, Is this a typo? on line 40 in asr.c #define DEFAULT_CONF"lookup bind file\nameserver 127.0.0.1\n" should it be "lookup bind file\nnameserver 127.0.0.1\n"? regards, -peter It was a typo indeed, tarball has been updated and also contains a fix for a crash experienced by todd@ when using "relay via" Gilles
Re: smtpd w/ async DNS
On Sat, Oct 30, 2010 at 04:55:36PM +0200, Gilles Chehade wrote: > Hi tech@, > > A new tarball with all reported issues fixed is available at: > > http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz > > smtpd now catches changes in /etc/resolv.conf and should work fine with > inet6 records. > I have done some stress testing here and it's been stable. > > asr has also been improved by eric@ who cleaned up code, fixed some bugs > and added tcp support, honors the family keyword in /etc/resolv.conf. > > Please test fast and report issues so that we can move to the next > features ;-) > > Gilles Hi, Is this a typo? on line 40 in asr.c #define DEFAULT_CONF"lookup bind file\nameserver 127.0.0.1\n" should it be "lookup bind file\nnameserver 127.0.0.1\n"? regards, -peter
Re: smtpd w/ async DNS
On 10/15/10 10:50, Gilles Chehade wrote: Hi tech@, A new tarball has been uploaded yesterday, it contains the fixes eric@ wrote for the issues reported on asr. For now, only two issues have been reported on smtpd: 1- smtpd does not catch up changes to /etc/resolv.conf; 2- smtpd does not look ip records; I will not have internet access until Monday but 1- should be fixed by then and I'll fix 2- and republish a tarball to test before I commit to the tree If you ran into another issue, please let me know Gilles Hi tech@, A new tarball with all reported issues fixed is available at: http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz smtpd now catches changes in /etc/resolv.conf and should work fine with inet6 records. I have done some stress testing here and it's been stable. asr has also been improved by eric@ who cleaned up code, fixed some bugs and added tcp support, honors the family keyword in /etc/resolv.conf. Please test fast and report issues so that we can move to the next features ;-) Gilles
Re: less stupid kshrc example
On 2010/10/29 21:55, Andres Perera wrote: > Defining a bunch of functions just to update the term title is > ridiculous. I use this. Also it's a good way to find bugs in cwm :) > --- src/etc/ksh.kshrc.origFri Oct 29 21:40:51 2010 > +++ src/etc/ksh.kshrc Fri Oct 29 21:51:48 2010 > @@ -45,16 +45,7 @@ > HOSTNAME=${HOSTNAME:-`uname -n`} > HOST=${HOSTNAME%%.*} > > - PROMPT="$USER:!$PS1S" > - #PROMPT="<$u...@$host:!>$PS1S" > - PPROMPT='$USER:$PWD:!'"$PS1S" > - #PPROMPT='<$u...@$host:$PWD:!>'"$PS1S" > - PS1=$PPROMPT > - # $TTY is the tty we logged in on, > - # $tty is that which we are in now (might by pty) > - tty=`tty` > - tty=`basename $tty` > - TTY=${TTY:-$tty} > + PS1='\...@\h:\w \$ ' > > set -o emacs > > @@ -70,82 +61,29 @@ > ;; > esac > case "$TERM" in > - sun*-s) > - # sun console with status line > - if [ "$tty" != "$console" ]; then > - # ilabel > - ILS='\033]L'; ILE='\033\\' > - # window title bar > - WLS='\033]l'; WLE='\033\\' > - fi > + dtterm*|screen*|rxvt*|xterm*) > + ILS="\e]1;" > + ILE="\a" > + WLS="\e]2;" > + WLE="\a" > ;; > - xterm*) > - ILS='\033]1;'; ILE='\007' > - WLS='\033]2;'; WLE='\007' > - parent="`ps -ax 2>/dev/null | grep $PPID | grep -v grep`" > - case "$parent" in > - *telnet*) > - export TERM=xterms;; > - esac > + ''|dumb|vt220) > + true > ;; > - *) ;; > + *) > + if tput hs >/dev/null 2>&1; then > + WLS=`tput ts` > + WLE=`tput fs` > + fi > + ;; > esac > - # do we want window decorations? > - if [ "$ILS" ]; then > - ilabel () { print -n "${ILS}$*${ILE}">/dev/tty; } > - label () { print -n "${WLS}$*${WLE}">/dev/tty; } > - > - alias stripe='label "$u...@$host ($tty) - $PWD"' > - alias istripe='ilabel "$u...@$host ($tty)"' > - > - wftp () { ilabel "ftp $*"; "ftp" "$@"; eval istripe; } > - wcd () { \cd "$@" && eval stripe; } > - wssh () > - { > - local rc > - "ssh" "$@" > - rc=$? > - eval istripe > - eval stripe > - return $rc > - } > - wtelnet () > - { > - local rc > - "telnet" "$@" > - rc=$? > - eval istripe > - eval stripe > - return $rc > - } > - wrlogin () > - { > - local rc > - "rlogin" "$@" > - rc=$? > - eval istripe > - eval stripe > - return $rc > - } > - wsu () > - { > - local rc > - "su" "$@" > - rc=$? > - eval istripe > - eval stripe > - return $rc > - } > - alias su=wsu > - alias cd=wcd > - alias ftp=wftp > - alias ssh=wssh > - alias telnet=wtelnet > - alias rlogin=wrlogin > - eval stripe > - eval istripe > - PS1=$PROMPT > + if [ -n "$ILS" ]; then > + PS1="$ps1\[$il...@\h$ile\]" > fi > + if [ -n "$WLS" ]; then > + PS1="$ps1\[$wl...@\h \w$WLE\]" > + fi > + unset ILS ILE WLS WLE > alias quit=exit > alias cls=clear > alias logout=exit
Re: sync adduser with installer
* Brynet [2010-10-30 11:12]: > All I was trying to communicate is that the exposure of a users home > directory is something that must be dealt with by system administrators > or preferably by the individual users themselves. [ ] you grok "sane defaults" -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: sync adduser with installer
Paul de Weerd wrote: > Welcome, to the real world. Users are incapable of just about > anything. Except for fucking things up, they're extremely good at > that. Live with it. So wait, are you for or against creating lone groups for individual users? All I was trying to communicate is that the exposure of a users home directory is something that must be dealt with by system administrators or preferably by the individual users themselves. By default on OpenBSD, home directories are world readable, the installer (..if directed) uses user(8) tools to create a default account, this adds the user to the shared 'users' group. This is expected behaviour for people who use the user(8) tools directly, all users can read each others files and if they're in the same group can even allow write access for shared work. It seems people using adduser(8) are accustomed to having world readable files, and no shared group by default. People should really take a look at the default permissions in /home on a case-by-case basis (..who is on the system, how many users) and choose permissions that make sense.. educating users about the your system defaults and how to change them also makes a lot of sense. Changing behaviour of either command is quite likely to wake a few people up, but, that's life.. they will have to deal with it. :-) -Bryan.
Re: sync adduser with installer
On Sat, Oct 30, 2010 at 01:12:54AM -0400, Brynet wrote: | Daniel wrote: | > Same here. Really, I'm surprised that anyone is using the 'users' | > group at all these days, especially on OpenBSD. If all users are in | > the same group, group permissions are no different from world | > permissions. | | I believe the real problem here is that you're allowing users on your | systems that are incapable of properly setting the group/world | permissions of their home directories. Welcome, to the real world. Users are incapable of just about anything. Except for fucking things up, they're extremely good at that. Live with it. Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Izgledaj super, osvoji nagrade, uključi se u igru!
Top Shop Saznaj koji si tip, oblikuj svoje telo - izgledaj seksi i osvoji SUPER nagrade! E=eliš lepo i privlaD no telo uz bolju ishranu i veE>be koje nisu zahtevne? Power Track Plus Total Vibes Deluxe Sationary Home Gym Da li je tvoja zadnjica prevelika? Kukovi preširoki? UkljuD i se u igru ;Kakav si tip?+ Doteraj figuru bez muke osvoji kupon za BESPLATNU DOSTAVU bilo kog Top Shop fitnes proizvoda i e-knjigu o seksu. Klikni ovde i uD estvuj! Jednostavno je: ⢠UD estvuj u igri i saznaj sve o svom tipu graDe i oblikuj telo uz prave veE>be i pravilnu ishranu! ⢠PreporuD i i prijateljima - osvoji bodove i uD estvuj u trci za super nagrade! ⢠Preuzmi svoj primerak besplatne E-knjige o seksu ⢠Osvoji kupon za besplatnu dostavu na SVE Top Shop proizvode! ⢠Svakih 10 dana 1 ekstra fitnes nagrada za onog ko ukljuD i najviše prijatelja! KLIKNI OVDE i ukljuD i se odmah! [Klikom na ove linkove automatski uzimate uD ešDe u testu i potvrDujete da se slaE>ete sa svim pravilima i uslovima uD ešDa. Pravila testa moE>ete proD itati ovde.] Bonus nagrada Bonus nagrada! Besplatna dostava Besplatna dostava! E-knjiga o seksu Besplatna E-knjiga o seksu! Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu, uD estvovali u posebnim akcijama ili poklon igri na sajtu www.top-shop.rs Ukoliko ne E>elite više da primate naše elektronske poruke, za odjavljivanje sa emailing liste kliknite ovde i ispišite svoju adresu iz Top Shop e-mail baze podataka. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08, E-mail: i...@top-shop.rs [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.