Re: off topic Question of the day..

[John Hasler]

Dennis writes:
> BTW: one inch now equals 2.54 cm *exactly*, in case you haven't been
> keeping up! (Used to be approx 2.54 cm.) This is what I mean by
> arbitrary. Don't like the conversion ratio?  Then just change it!

It wasn't a change in conversion ratio.  It was change in definition.
Originally US length measures were defined by a physical standard
derived from the British yard such that the inch worked out to close to
2.54cm.  In 1893 the inch was defined as 2.54cm and BIPM-supplied meter
and kilogram standards became the official US measurement standards.  It
took until 1930 for the Brits to catch up.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: off topic Question of the day..

[David Wright]

On Thu 14 Jul 2016 at 11:21:25 (-0500), Dennis Wicks wrote:
> Doug wrote on 07/10/2016 10:22 PM:
> >I've seen several places where this definition is shown, so it must be 
> >correct.
> >If you Google
> >for paper weight, there will be at least one site that mentions paper weight 
> >in
> >pounds and
> >also in grams / cm-squared, which may make sense to the Europeans reading 
> >this but
>that would be square-cm.
> >not to me!
> 
> I'm with you!
> 
> Personally, I have never seen a sensible justification for switching
> from one arbitrary measurement system (foot, pound, quart) to
> another arbitrary measurement system (meter, gram, liter).

Is that the International Foot or the US Survey Foot, the Avoirdupois
Pound or the Troy Pound, the Imperial Quart or the US Quart?

But you're just comparing the units here, not the system which also
includes how the units relate to one another. There's a multiplicity
of multiples to with any non-metric system, which we had to learn
at school. 12, 3, 220, 8 for distances, 16, 16, 14, 8, 20 for weight,
4, 2, 4, 2, 4 for volume. That's before you looked at areas, 4840, 640,
and volumes, 2219.36 cu in per bushel. No, we didn't have to learn
that last one.

> BTW: one inch now equals 2.54 cm *exactly*, in case you haven't been
> keeping up! (Used to be approx 2.54 cm.) This is what I mean by
> arbitrary. Don't like the conversion ratio? Then just change it!

The problem with measuring paper by weight is of course that the
amount weighed is never unambiguously specified, and varies
according to what sort of paper is being specified. That's why
I said you need to serve an apprenticeship in printing, so you
can tell whether the paper is bond, cover, Bristol or book,
amongst others... And you have to hope that your supplier uses the
normal basis weight, which is not actually fixed, only conventional.

Cheers,
David.

Re: Desmontar carpetas muertas

[ziprasidone146939...@gmail.com]

On Monday, July 11, 2016 09:04:45 PM Paynalton wrote:
> Hola chicos, tengo un problema. En un servidor tengo varios montajes a
> carpetas cifs. El problema es que a veces esos servidores pierden
> comunicación y las carpetas se cuelgan.
> 
> el montaje lo tengo así:
> 
> 
> //1.1.1.1/carpeta /mnt/carpetacifs
> user=usuario,password=password,auto,user,ro   0 0
> 
> He intentado lo siguiente:
> 
> umount /mnt/carpeta
> umount -fl /mnt/carpeta
> umount -fr /mnt/carpeta
> umount -l /mnt/carpeta
> 
> y comandos como estos también se quedan colgados:
> 
> fuser /mnt/carpeta
> df
> cd /mnt/carpeta
> 
> Si reinicio el servidor también se queda colgado, la única forma de
> desbloquear es desconectar el servidor y esperar a que encienda de
> nuevo.
> 
> Saben de que manera puedo reestablecer una conexión en estos casos???

Hola

Tengo un caso similar; tenemos un servidor samba (llamemoslo A) en el que 
algunos de sus shares apuntan (montados por nfs y smb) a otro servidor (B). 

Creo que este caso es aún peor, ya que si el servidor (B), que es el que 
contiene la información de esos shares..., se apaga, el servidor (A) de samba 
se cuelga totalmente (no exactamente el servidor, sino que el servicio samba 
deja de responder; también como el caso del OP, hasta que "B" vuelva a estar 
en línea).

Quedo atento si surge una solucion.

PD: Creo recordar (no estoy 100% seguro) que en versiones anteriores esto no 
ocurría.

Saludos

Re: Resolvido, extremamente lento para gravar em pendrive (memória flash).

[Herberson da Silva Miranda]

Paulino,

Aqui no meu os valores estão bem diferentes,

vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500


Em 15-07-2016 16:46, Paulino Kenji Sato escreveu:
> Ola,
> A muito tempo que estava tentando resolver um problema de gravação em
> pendrive (e outras mídias flash). A gravação após certo tempo ficava
> extremamente lento, principalmente com arquivos grandes (GB), a tal
> ponto de ter que deixar de um dia para outro para que a gravação fosse
> concluída.
> Isso pode ser devido a ainda estar usando o Debian 6.0.10. (eu sei, e
> antigo... Isso não vem ao caso...)
> De tempos em tempos pesquisava sobre o assunto. Até que algumas
> semanas atrás achei alguma informação relevante.
> Em sistemas x86-64, quando com kernel 64bits, parece haver um problema
> de temporização quando se esta enviando dados para algo "lento" como
> um pendrive USB. Pode ser um bug do kernel ou ser o comportamento do
> hardware. A solução sugerida era ajustar alguns parâmetros no sysctl,
> que são:
> vm.dirty_background_bytes = 16777216
> vm.dirty_bytes = 50331648
>
> Como não sei se isso persiste nas versões atuais do kernel, estou
> deixando essa dica aqui.
>
>
> --
> Paulino Kenji Sato

-- 
Att,
Herberson S. Miranda
Twitter: @__von
Website: http://0fx66.com/
OpenPGP: 0x66F9A5F0
Skype: h.s.miranda

[]'s

Re: What pkg provides openssl headers?

[mudongliang]

On 07/15/2016 05:14 PM, Nicholas Geovanis wrote:
Hi - I'm somewhat new to debian. I'm building the nagios NRPE plugin 
on Debian Jessie. Its configure script fails the check for SSL header 
files with "Cannot find SSL headers". Which Debian package provides 
them? Thanks.Nick
Please refer to this url : 
http://askubuntu.com/questions/133184/nagios-nrpe-installation-errorconfigure-error-cannot-find-ssl-libraries


Best Regards
Dongliang Mu

Re: What pkg provides openssl headers?

[mudongliang]

On 07/15/2016 05:14 PM, Nicholas Geovanis wrote:
Hi - I'm somewhat new to debian. I'm building the nagios NRPE plugin 
on Debian Jessie. Its configure script fails the check for SSL header 
files with "Cannot find SSL headers". Which Debian package provides 
them? Thanks.Nick

Maybe you need libssl-dev libssl1.0.2.
You can search it by "apt search libssl" in your own OS.

Best Regard
Dongliang Mu

What pkg provides openssl headers?

[Nicholas Geovanis]

Hi - I'm somewhat new to debian. I'm building the nagios NRPE plugin on
Debian Jessie. Its configure script fails the check for SSL header files
with "Cannot find SSL headers". Which Debian package provides them?
Thanks.Nick

Resolvido, extremamente lento para gravar em pendrive (memória flash).

[Paulino Kenji Sato]

Ola,
A muito tempo que estava tentando resolver um problema de gravação em
pendrive (e outras mídias flash). A gravação após certo tempo ficava
extremamente lento, principalmente com arquivos grandes (GB), a tal ponto
de ter que deixar de um dia para outro para que a gravação fosse concluída.
Isso pode ser devido a ainda estar usando o Debian 6.0.10. (eu sei, e
antigo... Isso não vem ao caso...)
De tempos em tempos pesquisava sobre o assunto. Até que algumas semanas
atrás achei alguma informação relevante.
Em sistemas x86-64, quando com kernel 64bits, parece haver um problema de
temporização quando se esta enviando dados para algo "lento" como um
pendrive USB. Pode ser um bug do kernel ou ser o comportamento do hardware.
A solução sugerida era ajustar alguns parâmetros no sysctl, que são:
vm.dirty_background_bytes = 16777216
vm.dirty_bytes = 50331648

Como não sei se isso persiste nas versões atuais do kernel, estou deixando
essa dica aqui.


--
Paulino Kenji Sato

Re: using curl/wget to call logout

[Bob]

On Friday 15 July 2016 10:28 AM, Jonathan Dowland wrote:

On Fri, Jul 15, 2016 at 05:40:40AM +, Bob wrote:

I'm trying to use curl to call the logout function of a logout button
already working through browser.

snip

already tried with

curl -c my.cookie  /home.jsp
curl -X GET -c my.cookie /Login.jsp?message=logout

but no success. How can I use curl/wget to logout through CLI ?

It would be helpful if instead of 'no success' you provided precisely what
did happen and what output/return code you got.

The problem here, or really the behaviour you are asking questions about, is
specific to whichever device you are trying to interact with, and is not really
a wget question. Without knowing the device, there's little we can do to help
you.

You might need to set HTTP Auth headers for the wget request. If that were the
case, the result of trying without would indicate that authentication was
required.

Cloning the session cookie from your browser won't work; the session management
code in your device is designed to prevent you doing that. You will likely need
to initiate a new session from a script, and use the cookie /that/ process sets
for the request to press the poweroff button.

You could try getting wget to set the referrer, you could also try asking wget
to use the same User-Agent string as your browser.



Hi Jonathan,

Thanks for your response.  I need to login/out from a web-based form of 
ISP to enable/disable internet. I'm trying do the same from console with 
curl/wget. Now I have dig more and found following source code when 
logged in, wonder how to use it with curl/wget to call the logout function.


~~~

function logout(){
var out = confirm ('Do you really want to Logout ?')
if(out){
document.forms["logoutForm"].submit();
}
}
function logoutbut(){
var out = confirm ('Do you really want to Logout ?')
if(out){
document.forms["logoutbut"].submit();
}
}


id="logoutForm" style="margin-top: 0px;">

Welcome   
 Logout
value="">

~

here  is provided by the ISP

regards,
Bob

Re: [OT-Ubuntu] Foros de Ubuntu vulnerados

[Felix Perez]

El día 15 de julio de 2016, 13:32, limpia  escribió:
> On 2016-07-15 12:16, Camaleón wrote:
>>
>> Hola,
>>
>> Como seguramente haya gente de por aquí con acceso a los foros de Ubuntu,
>> pongo el aviso oficial:
>>
>> Notice of security breach on Ubuntu Forums
>>
>> http://insights.ubuntu.com/2016/07/15/notice-of-security-breach-on-ubuntu-forums/
>>
>> Parece ser que han podido acceder a la base de datos de usuarios aunque
>> no a las contraseñas, aún así quien tenga cuenta en los susodichos foros
>> que se entere bien de lo que recomiendan hacer.
>>
>> Si es que no hay nada como las listas de correo públicas porque lo que
>> está muerto no puede morir y lo que está abierto no puede ser vulnerado
>> :-)
>>
>> Saludos,
>
>
> Buenos tarde, y
> Gracias por este informacione, o anuncio,
>  Una pregunta, fuera de tema, pero es mejor para responder en la parte
> superior de un poste
> o la parte inferior, como lo hice aquí, ..
>

Abajo de lo que quieras responder, tal y como un dialogo verbal.

normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html


Saludos.
-- 
usuario linux  #274354
normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html

Re: [OT-Ubuntu] Foros de Ubuntu vulnerados

[limpia]

On 2016-07-15 12:16, Camaleón wrote:

Hola,

Como seguramente haya gente de por aquí con acceso a los foros de 
Ubuntu,

pongo el aviso oficial:

Notice of security breach on Ubuntu Forums
http://insights.ubuntu.com/2016/07/15/notice-of-security-breach-on-ubuntu-forums/

Parece ser que han podido acceder a la base de datos de usuarios aunque
no a las contraseñas, aún así quien tenga cuenta en los susodichos 
foros

que se entere bien de lo que recomiendan hacer.

Si es que no hay nada como las listas de correo públicas porque lo que
está muerto no puede morir y lo que está abierto no puede ser vulnerado
:-)

Saludos,


Buenos tarde, y
Gracias por este informacione, o anuncio,
 Una pregunta, fuera de tema, pero es mejor para responder en la parte 
superior de un poste

o la parte inferior, como lo hice aquí, ..

--
 Ahora, en Español,
¿Cómo no romper Debian :(Don'tBreakDebian)
https://wiki.debian.org/es/DontBreakDebian

[OT-Ubuntu] Foros de Ubuntu vulnerados

[Camaleón]

Hola,

Como seguramente haya gente de por aquí con acceso a los foros de Ubuntu, 
pongo el aviso oficial:

Notice of security breach on Ubuntu Forums
http://insights.ubuntu.com/2016/07/15/notice-of-security-breach-on-ubuntu-forums/

Parece ser que han podido acceder a la base de datos de usuarios aunque 
no a las contraseñas, aún así quien tenga cuenta en los susodichos foros 
que se entere bien de lo que recomiendan hacer.

Si es que no hay nada como las listas de correo públicas porque lo que 
está muerto no puede morir y lo que está abierto no puede ser vulnerado 
:-)

Saludos,

-- 
Camaleón

Re: C source

[Nicolas George]

L'octidi 28 messidor, an CCXXIV, Jonathan Dowland a écrit :
> Interesting nuance, thanks!
> 
> I wonder if this is why SDL recommends people just use "" for their
> own headers.

The best explanation I can come up with is that their examples where
originally designed as test programs within the source tree. In that case,
the double quote form is not incorrect. Then they forgot to update it when
turning it into examples and documentation.

The <> / "" distinction is always in a grey area when a project is
constructed as a library plus programs using it. My rule of thumb would be
to use "" for tests programs within the library and <> for examples meant
for outside developers using the library. In fact, the example should be
written to work with the library fully installed and the build tree purged,
although they should include Makefile magic to work directly from the build
tree too.

I think that having "" fall back to searching the system headers like <>
does is a bad design decision and encourages sloppy practices. Of course, it
is way too late to fix that now. #include "stdio.h" should be as much an
error as #include .

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Crypto implementations (was: C source)

[Nicolas George]

L'octidi 28 messidor, an CCXXIV, Jonathan Dowland a écrit :
> Do not CC me, I am subscribed to the list. This is clear in the CoC
> for lists.debian.org,

Not CCing this once. I recently explained in great length why this point of
the CoC is broken and should be ignored.

>   and it's prominently in the mail signature of
> my mail you replied to.

The correct place for that is the message header, not the signature.
Signatures are cosmetic, nobody reads them, the message header is meant to
control the operations.

> Can't miss an opportunity to go all Comic-Book-Guy on your audience!

I have no idea what that means.

> There's obviously a trade-off between re-use a library and cargo-cult some 
> code
> when implementing something. MD5 is small and simple enough that it falls on
> the former side of that line a lot of the time, especially if the alternative 
> is including a heavy weight library dependency like OpenSSL. One's mileage may
> vary depending on the nature of one's particular project.
> 
> If it was good enough for dpkg...

Too bad you snipped the other paragraph, which was the important part of my
message. Especially the part about the 30% speed difference.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: C source

[Jonathan Dowland]

On Fri, Jul 15, 2016 at 02:59:12PM +0200, Andre Majorel wrote:
> The rule of thumb of using "" for application headers and <> for
> system headers is valid. But a more accurate way to summarise
> the difference would be that #include <> only looks at the
> system directories.

Interesting nuance, thanks!

I wonder if this is why SDL recommends people just use "" for their
own headers.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: Crypto implementations (was: C source)

[Jonathan Dowland]

Do not CC me, I am subscribed to the list. This is clear in the CoC
for lists.debian.org, and it's prominently in the mail signature of
my mail you replied to.

On Fri, Jul 15, 2016 at 12:36:46PM +0200, Nicolas George wrote:
> L'octidi 28 messidor, an CCXXIV, Jonathan Dowland a écrit :
> > FWIW, last time I wanted to do md5 in C, I copied the code into my own
> > project. I got it from the source to dpkg, which did the same thing.
> 
> By doing that, you are depriving yourself of future bugfixes and
> improvements to that implementation. Well, MD5 is pretty much set in stone
> and can be completely tested, so it is not a serious concern, but I wanted
> to underline it for the record.

Can't miss an opportunity to go all Comic-Book-Guy on your audience!

There's obviously a trade-off between re-use a library and cargo-cult some code
when implementing something. MD5 is small and simple enough that it falls on
the former side of that line a lot of the time, especially if the alternative 
is including a heavy weight library dependency like OpenSSL. One's mileage may
vary depending on the nature of one's particular project.

If it was good enough for dpkg...


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: (deb-cat) cups-browsed en catala

[Narcis Garcia]

Curiós; he avançat fins a aïllar en una nova instal·lació que:
No cal afegir llengües al M.Firefox per aconseguir veure el CUPS en
català; Cal fer això:

1. Menú -> Preferències -> Contingut -> Llengües>Trieu
2. Seleccioneu Català, que ja hauria d'estar en primera posició
3. [Mou avall]
4. [Mou amunt] -> Altra vegada en primera posició.

i ja està. Per veure'n l'efecte es pot [Actualitzar] la pàgina del CUPS.
http://localhost:631/


El 15/06/16 a les 21:20, Eduard Selma ha escrit:
> El 15/06/16 a les 20:41, Ernest Adrogué ha escrit:
> ..
> 
> 
>> A /usr/share/cups/templates/ hi ha 4 directoris: ja de ru es.  Però
>> ara veig
>> que hi ha més fitxers a /usr/share/cups/locale/ entre ells, ca.  Tot i
>> això
>> sembla que perquè surti en català has de tenir el local ca_ES a nivell de
>> sistema (?).
> 
> - Efectivament, jo tinc el locale com a ca_ES.UTF-8
> 
> I com ja he dit, em sembla que a Wheezy i anteriors, el veia en anglès.
> 
> 
> Eduard Selma
> 

Re: C source

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jul 15, 2016 at 02:59:12PM +0200, Andre Majorel wrote:
> On 2016-07-15 11:54 +0200, to...@tuxteam.de wrote:
> 
> > As your includes are written above, the C compiler would look
> > for a file md5.h in the current compilation directory: most
> > probably there isn't one, since whatever package you installed
> > will put it in a standard system location, typically under
> > /usr/include.
> 
> On 2016-07-15 12:56 +0300, Reco wrote:
> 
> > #include with encased in 'less' and 'more' characters instructs
> > preprocessor to search header files system-wide. A search path can be
> > modified with -L flag.
> > 
> > #include with quotes instructs preprocessor to search a header file in
> > the current directory.
> > 
> > So probably you meant to write this:
> > 
> > #include 
> 
> to...@tuxteam.de & Reco's statements could give the impression
> that #include <*> searches the standard system include
> directories (/usr/include et al.) while #include "*" searches
> the current working directory. That's misleading in that
> #include "*" also searches the directories that #include <*>
> does.
> 
> The standard explicitly says so (see [#3] in 6.10.2 in n869, for
> instance).

Yep, you are right.

> So trying to make cpp find a header by replacing the "" by <> is
> not likely to work.

ack.

> The rule of thumb of using "" for application headers and <> for
> system headers is valid. But a more accurate way to summarise
> the difference would be that #include <> only looks at the
> system directories.

again, ack.

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAleI5GgACgkQBcgs9XrR2kZwIgCfWCXUwPjnXNY7DrHp+Nh2RA1j
UWwAnA4yi7K9rj8qZZf1EmMOyjuV4WaF
=y7ea
-END PGP SIGNATURE-

Re: C source

[Andre Majorel]

On 2016-07-15 11:54 +0200, to...@tuxteam.de wrote:

> As your includes are written above, the C compiler would look
> for a file md5.h in the current compilation directory: most
> probably there isn't one, since whatever package you installed
> will put it in a standard system location, typically under
> /usr/include.

On 2016-07-15 12:56 +0300, Reco wrote:

> #include with encased in 'less' and 'more' characters instructs
> preprocessor to search header files system-wide. A search path can be
> modified with -L flag.
> 
> #include with quotes instructs preprocessor to search a header file in
> the current directory.
> 
> So probably you meant to write this:
> 
> #include 

to...@tuxteam.de & Reco's statements could give the impression
that #include <*> searches the standard system include
directories (/usr/include et al.) while #include "*" searches
the current working directory. That's misleading in that
#include "*" also searches the directories that #include <*>
does.

The standard explicitly says so (see [#3] in 6.10.2 in n869, for
instance).

So trying to make cpp find a header by replacing the "" by <> is
not likely to work.

The rule of thumb of using "" for application headers and <> for
system headers is valid. But a more accurate way to summarise
the difference would be that #include <> only looks at the
system directories.

-- 
André Majorel 
lists.debian.org, a spammer's favourite.

Containers and chroot (was: openssh-server's default config is dangerous)

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Stefan Monnier a écrit :
> FWIW, I also find it disappointing that I can't do it in an etc file of
> some sort.

Yes, such an essential option should be integral to the system, not brought
by an obscure package. That the package exists is still better than nothing,
though.

> E.g. I often need something like this when running inside
> a chroot and always have trouble finding the clean way to do it
> (IIUC dpkg should figure out on its own that it's running in a chroot,
> but it doesn't seem to work reliably enough in my experience, or maybe
> I misunderstood how "running in chroot" is expected to affect dpkg's
> behavior by default).

If both the outer and the inner systems use systemd, then you can use
systemd-nspawn instead of chroot. It will isolate a little more at the
kernel level (using namespaces) and mount the essential pseudo-filesystems,
and more importantly it starts a sub-instance of systemd that isolate the
services.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: using curl/wget to call logout

[Justin Steven]

>From Chromium's Development Tools (press F12) you can right-click a request in
the Network tab and "Copy as cURL"

Might help with handling cookies and other such things using curl

-- 
Justin

Crypto implementations (was: C source)

[Nicolas George]

L'octidi 28 messidor, an CCXXIV, Jonathan Dowland a écrit :
> FWIW, last time I wanted to do md5 in C, I copied the code into my own
> project. I got it from the source to dpkg, which did the same thing.

By doing that, you are depriving yourself of future bugfixes and
improvements to that implementation. Well, MD5 is pretty much set in stone
and can be completely tested, so it is not a serious concern, but I wanted
to underline it for the record.

More importantly, by doing that, you are depriving yourself of all
optimizations that were introduced in more mature crypto libraries. Since
MD5 is computationally intensive, this is a serious concern. If your project
only does a few MD5 on small chunks of data while spending most of its time
in other tasks, then it is certainly fine. Otherwise, this is a very bad
idea. The difference is quite significant, sometimes more than 30% depending
on the hardware.

I have found that OpenSSL's implementation was the fastest amongst readily
available crypto implementations (gcrypt, libtomcrypt, libavutil).

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: C source

[Thomas Schmitt]

Hi,

Pol Hallen wrote:
> now I've many errors
> alice.c:50:18: error: unknown type name ‘md5_context’
> alice.c:61:37: error: unknown type name ‘uint8’

This might indicate that openssl/md5.h is not the md5.h which is needed
for your source code. If so, then  was rather a red herring.
(One can be right and misleading at the same time.)

Your alice.c would want to see a companion file md5.h from its own family.
Probably you find it where you found alice.c.


Have a nice day :)

Thomas

Re: C source

[Jonathan Dowland]

On Fri, Jul 15, 2016 at 12:23:01PM +0200, Jens Sauer wrote:
> I think you are missing dependencies from the ssl library. Have a look into
> the docs [1].

Doesn't look like openssl to me. Openssl just happens to also have a md5.h
header in it.


signature.asc
Description: Digital signature

Re: using curl/wget to call logout

[Jonathan Dowland]

On Fri, Jul 15, 2016 at 05:40:40AM +, Bob wrote:
> I'm trying to use curl to call the logout function of a logout button
> already working through browser.
snip
> already tried with
> 
> curl -c my.cookie  /home.jsp
> curl -X GET -c my.cookie /Login.jsp?message=logout
> 
> but no success. How can I use curl/wget to logout through CLI ?

It would be helpful if instead of 'no success' you provided precisely what
did happen and what output/return code you got.

The problem here, or really the behaviour you are asking questions about, is
specific to whichever device you are trying to interact with, and is not really
a wget question. Without knowing the device, there's little we can do to help
you.

You might need to set HTTP Auth headers for the wget request. If that were the
case, the result of trying without would indicate that authentication was
required.

Cloning the session cookie from your browser won't work; the session management
code in your device is designed to prevent you doing that. You will likely need
to initiate a new session from a script, and use the cookie /that/ process sets
for the request to press the poweroff button.

You could try getting wget to set the referrer, you could also try asking wget
to use the same User-Agent string as your browser.


-- 
Jonathan Dowland
✎ j...@dow.land
 jmtd.net

Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: C source

[Jens Sauer]

I think you are missing dependencies from the ssl library. Have a look into
the docs [1].

Your questions implies that you are not very experienced in C coding.
Maybe you should ask yourself the question if starting with a complex and
potential security risky api like openssl is the right thing for a beginner.

Happy coding

[1] https://www.openssl.org/docs/manmaster/ssl/ssl.html

Am 15.07.2016 12:07 nachm. schrieb "Pol Hallen" :

sorry, my mistake about the package (I use debian testing)

  find /usr/include -name md5.h
>

find /usr/include/ -name md5.h
/usr/include/openssl/md5.h
/usr/include/crypto++/md5.h

  #include 
>

now I've many errors

thanks for help!

alice.c:50:18: error: unknown type name ‘md5_context’
 void md5_starts( md5_context *ctx )
  ^
alice.c:61:19: error: unknown type name ‘md5_context’
 void md5_process( md5_context *ctx, uint8 data[64] )
   ^
alice.c:61:37: error: unknown type name ‘uint8’
 void md5_process( md5_context *ctx, uint8 data[64] )
 ^
alice.c:184:18: error: unknown type name ‘md5_context’
 void md5_update( md5_context *ctx, uint8 *input, uint32 length )
  ^
alice.c:184:36: error: unknown type name ‘uint8’
 void md5_update( md5_context *ctx, uint8 *input, uint32 length )
^
alice.c:184:50: error: unknown type name ‘uint32’
 void md5_update( md5_context *ctx, uint8 *input, uint32 length )
  ^
alice.c:223:8: error: unknown type name ‘uint8’
 static uint8 md5_padding[64] =
^
alice.c:231:18: error: unknown type name ‘md5_context’
 void md5_finish( md5_context *ctx, uint8 digest[16] )
  ^
alice.c:231:36: error: unknown type name ‘uint8’
 void md5_finish( md5_context *ctx, uint8 digest[16] )
^
alice.c: In function ‘main’:
alice.c:299:3: error: unknown type name ‘md5_context’
   md5_context ctx;
   ^
alice.c:321:3: warning: implicit declaration of function ‘md5_starts’
[-Wimplicit-function-declaration]
   md5_starts(  );
   ^
alice.c:325:7: warning: implicit declaration of function ‘md5_update’
[-Wimplicit-function-declaration]
   md5_update( , buf, i );
   ^
alice.c:332:3: warning: implicit declaration of function ‘md5_finish’
[-Wimplicit-function-declaration]
   md5_finish( , md5sum );
   ^


Pol

Re: C source

[Jonathan Dowland]

On Fri, Jul 15, 2016 at 12:07:09PM +0200, Pol Hallen wrote:
> alice.c:50:18: error: unknown type name ‘md5_context’
>  void md5_starts( md5_context *ctx )

These aren't typedefs used by openssl.  It looks like your code
is designed to be used with a completely different md5.h.

FWIW, last time I wanted to do md5 in C, I copied the code into my own
project. I got it from the source to dpkg, which did the same thing.

https://github.com/chocolate-doom/chocolate-doom/commit/09180d3f73e522c1e0c43993aec28cf339dcf74d#diff-2fd6f21ae40fa979b9535d9f78ae4f0d

> alice.c:61:37: error: unknown type name ‘uint8’
>  void md5_process( md5_context *ctx, uint8 data[64] )
>  ^

This code must rely on some header or library defining a bunch of integer
types. uint8 is clearly meant to be an unsigned char. There's a standard
header  that gives you uint8_t and friends, but not without
the _t suffix.  inttypes.h is part of the ISO C99 standard and perhaps
others.

You need to find out what the actual dependencies of the code you are
trying to compile.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: C source

[Thomas Schmitt]

Hi,

i second tomás' assessment and proposal.


Reco wrote:
> #include with encased in 'less' and 'more' characters instructs
> preprocessor to search header files system-wide. A search path can be
> modified with -L flag.

It is not a system-wide search, but rather a search iterating over a list
of directory prefixes:
  https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html

That's why i agree with tomás that e.g.
  /usr/include/openssl/md5.h
should be used like

  #include 

because i expect that /usr/include is in the prefix list.

gcc -L is for libraries (-l):
  
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Directory-Options.html#Directory-Options
Own include directories are added by -I for 
  #include <...>
or -iquote for
  $include "..."


> #include with quotes instructs preprocessor to search a header file in
> the current directory.

But if not found there, the prefix list is searched, too.


Have a nice day :)

Thomas

Re: C source

[Nicolas George]

L'octidi 28 messidor, an CCXXIV, Pol Hallen a écrit :
> #include 
> #include 
> #include 
> #include "md5.h"

The fact that md5.h is included with double quotes instead of angle brackets
means that it is a header local to the project, not a system header. Your .c
file should come with the md5.h file. If it does not, it is bogus.

The suggestions of adding -I options, finding a file on the system or
installing a package are wrong, but they may become correct once the first
issue is fixed.

The suggestion about -L is completely wrong, -L is about linking, not
compiling.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: C source

[Pol Hallen]

sorry, my mistake about the package (I use debian testing)


  find /usr/include -name md5.h


find /usr/include/ -name md5.h
/usr/include/openssl/md5.h
/usr/include/crypto++/md5.h


  #include 


now I've many errors

thanks for help!

alice.c:50:18: error: unknown type name ‘md5_context’
 void md5_starts( md5_context *ctx )
  ^
alice.c:61:19: error: unknown type name ‘md5_context’
 void md5_process( md5_context *ctx, uint8 data[64] )
   ^
alice.c:61:37: error: unknown type name ‘uint8’
 void md5_process( md5_context *ctx, uint8 data[64] )
 ^
alice.c:184:18: error: unknown type name ‘md5_context’
 void md5_update( md5_context *ctx, uint8 *input, uint32 length )
  ^
alice.c:184:36: error: unknown type name ‘uint8’
 void md5_update( md5_context *ctx, uint8 *input, uint32 length )
^
alice.c:184:50: error: unknown type name ‘uint32’
 void md5_update( md5_context *ctx, uint8 *input, uint32 length )
  ^
alice.c:223:8: error: unknown type name ‘uint8’
 static uint8 md5_padding[64] =
^
alice.c:231:18: error: unknown type name ‘md5_context’
 void md5_finish( md5_context *ctx, uint8 digest[16] )
  ^
alice.c:231:36: error: unknown type name ‘uint8’
 void md5_finish( md5_context *ctx, uint8 digest[16] )
^
alice.c: In function ‘main’:
alice.c:299:3: error: unknown type name ‘md5_context’
   md5_context ctx;
   ^
alice.c:321:3: warning: implicit declaration of function ‘md5_starts’ 
[-Wimplicit-function-declaration]

   md5_starts(  );
   ^
alice.c:325:7: warning: implicit declaration of function ‘md5_update’ 
[-Wimplicit-function-declaration]

   md5_update( , buf, i );
   ^
alice.c:332:3: warning: implicit declaration of function ‘md5_finish’ 
[-Wimplicit-function-declaration]

   md5_finish( , md5sum );
   ^


Pol

Re: C source

[Pol Hallen]

#include 


I've same problem :-/


--
Pol

Re: C source

[Reco]

Hi.

On Fri, Jul 15, 2016 at 11:34:38AM +0200, Pol Hallen wrote:
> Hi, all
> 
> I've this error:
> 
> fatal error: md5.h: No such file or directory
> compilation terminated.
> 
> when I compiled a source C
> 
> gcc source.c
> 
> [...]
> #include 
> #include 
> #include 
> #include "md5.h"
> [...]
> 
> I've openssl-dev installed, but I don't understand how to audit this error..
> 
> any idea?

#include with encased in 'less' and 'more' characters instructs
preprocessor to search header files system-wide. A search path can be
modified with -L flag.

#include with quotes instructs preprocessor to search a header file in
the current directory.

So probably you meant to write this:

#include 

Reco

Re: C source

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jul 15, 2016 at 11:34:38AM +0200, Pol Hallen wrote:
> Hi, all
> 
> I've this error:
> 
> fatal error: md5.h: No such file or directory
> compilation terminated.
> 
> when I compiled a source C
> 
> gcc source.c
> 
> [...]
> #include 
> #include 
> #include 
> #include "md5.h"
> [...]
> 
> I've openssl-dev installed, but I don't understand how to audit this error..

Hmmm. I can't find a package named "openssl-dev" in Debian. What distro are
you using? How is the package called really?

As your includes are written above, the C compiler would look for a file
md5.h in the current compilation directory: most probably there isn't
one, since whatever package you installed will put it in a standard
system location, typically under /usr/include.

You can find that out by

  find /usr/include -name md5.h

Let's assume you get:

  /usr/include/openssl/md5.h

... then you'd have to tell your C compiler

  #include 

(there are many other ways to steer that, like the -I command line
option, but let's start with this).

regards

[1] 
https://packages.debian.org/search?keywords=openssl-dev=names=all=all

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAleIstkACgkQBcgs9XrR2kYo1wCcC/eqRU9M+YDQnsXggqC45FEr
9OwAnjHs8mX+vozUSpnB9upyjZb2TgqB
=+NJu
-END PGP SIGNATURE-

C source

[Pol Hallen]

Hi, all

I've this error:

fatal error: md5.h: No such file or directory
compilation terminated.

when I compiled a source C

gcc source.c

[...]
#include 
#include 
#include 
#include "md5.h"
[...]

I've openssl-dev installed, but I don't understand how to audit this error..

any idea?

thanks for help!

Pol

Re: (deb-cat) Dependencies no autoremovibles

[Narcis Garcia]

D'acord, gràcies.
Això implica que, a l'hora de provar un paquet, millor em copio la
llista de paquets associats per eliminar-lo després i deixar el sistema
com estava.



__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.

El 15/07/16 a les 10:04, Marcos ha escrit:
> A 2016-07-15 09:51, Narcis Garcia escrigué:
> 
>> PERÒ com podeu veure, el paquet "shared-mime-info" no està establert com
>> a «ja no necessari», i de fet amb un "apt-get autoremove" no marxa. Cal
>> desinstal·lar-lo expressament.
>>
>> Perquè succeeix això?
> 
> Potser perquè algun paquet ja instal·lat el té com a recomanat o suggerit
> i l'autoremove no el marca com desinsta·lable?
> 
> % apt-cache rdepends shared-mime-info --no-depends
> shared-mime-info
> Reverse Depends:
>   xlog
> shared-mime-info:i386
>   winff
>   citadel-webcit
> shared-mime-info:i386
>   python-sugar3
> shared-mime-info:i386
>   python-sugar-toolkit
> shared-mime-info:i386
>   retext
> shared-mime-info:i386
>   mypaint
> shared-mime-info:i386
>   libmono-system-windows-forms4.0-cil
> shared-mime-info:i386
>   libglib2.0-0
> shared-mime-info:i386
>   gdebi-kde
> shared-mime-info:i386
>   gdebi
> shared-mime-info:i386
>   desktop-profiles
> shared-mime-info:i386
>   citadel-client
> shared-mime-info:i386
>   citadel-server
> shared-mime-info:i386
> 
> El --no-depends és per veure només els paquets que suggereixen o
> recomanen el shared-mime-info.
> 
> Salut,

Re: (deb-cat) Dependencies no autoremovibles

[Marcos]

A 2016-07-15 09:51, Narcis Garcia escrigué:

PERÒ com podeu veure, el paquet "shared-mime-info" no està establert 
com

a «ja no necessari», i de fet amb un "apt-get autoremove" no marxa. Cal
desinstal·lar-lo expressament.

Perquè succeeix això?


Potser perquè algun paquet ja instal·lat el té com a recomanat o 
suggerit

i l'autoremove no el marca com desinsta·lable?

% apt-cache rdepends shared-mime-info --no-depends
shared-mime-info
Reverse Depends:
  xlog
shared-mime-info:i386
  winff
  citadel-webcit
shared-mime-info:i386
  python-sugar3
shared-mime-info:i386
  python-sugar-toolkit
shared-mime-info:i386
  retext
shared-mime-info:i386
  mypaint
shared-mime-info:i386
  libmono-system-windows-forms4.0-cil
shared-mime-info:i386
  libglib2.0-0
shared-mime-info:i386
  gdebi-kde
shared-mime-info:i386
  gdebi
shared-mime-info:i386
  desktop-profiles
shared-mime-info:i386
  citadel-client
shared-mime-info:i386
  citadel-server
shared-mime-info:i386

El --no-depends és per veure només els paquets que suggereixen o
recomanen el shared-mime-info.

Salut,
--
Marcos

Re: no sound

[Elimar Riesebieter]

* Jesse Stephen  [2016-07-15 00:31 -0400]:

> I don't seem to have sound on mazzila. It works playing a dvd but not on
> you tube

If you're running pulseaudio use pavucontrol to choose an
appropriate device. Otherwise run alsamixer and press  to select
your device.

Elimar
-- 
  Numeric stability is probably not all that
  important when you're guessing;-)

(deb-cat) Dependencies no autoremovibles

[Narcis Garcia]

En un ordinador he fet:

$ apt-get install latencytop
...
S'instaŀlaran els següents paquets extres:
  libatk1.0-0 libatk1.0-data libgtk2.0-0 libgtk2.0-bin libgtk2.0-common
libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxi6 libxinerama1
libxrandr2 shared-mime-info
...
(instal·lació exitosa)

Després:
$ apt-get remove latencytop
...
Els paquets següents s'han instaŀlat automàticament i ja no són necessaris:
  libatk1.0-0 libatk1.0-data libgtk2.0-0 libgtk2.0-bin libgtk2.0-common
libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxi6 libxinerama1
libxrandr2
...
(desinstal·lació exitosa)

PERÒ com podeu veure, el paquet "shared-mime-info" no està establert com
a «ja no necessari», i de fet amb un "apt-get autoremove" no marxa. Cal
desinstal·lar-lo expressament.

Perquè succeeix això?

-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.